X-Git-Url: https://git.xandkar.net/?a=blobdiff_plain;f=TODO;h=69ace9090ff10c91453beb93eea1af28186ccc6f;hb=HEAD;hp=d4979aef03a3f841ba0148eb7a140530aac31f9f;hpb=e678174b12c9efb68ca95b0ffe5ea1199e044343;p=tt.git

diff --git a/TODO b/TODO
index d4979ae..69ace90 100644
--- a/TODO
+++ b/TODO
@@ -10,7 +10,13 @@ Legend:
 
 In-progress
 -----------
-
+- [-] timeline limits
+  - [x] by time range
+  - [ ] by msg count
+    - [ ] per peer
+    - [ ] total
+      Not necessary for short format, because we have Unix head/tail,
+      but may be convinient for long format (because msg spans multiple lines).
 - [-] Convert to Typed Racket
   - [x] build executable (otherwise too-slow)
   - [-] add signatures
@@ -18,11 +24,16 @@ In-progress
     - [ ] inner
     - [ ] imports
 - [-] commands:
+  - [x] c | crawl
+    Discover new peers mentioned by known peers.
   - [x] r | read
     - see timeline ops above
   - [ ] w | write
     - arg or stdin
     - nick expand to URI
+    - Watch FIFO for lines, then read, timestamp and append [+ upload].
+      Can be part of a "live" mode, along with background polling and
+      incremental printing. Sort of an ii-like IRC experience.
   - [ ] q | query
     - see timeline ops above
     - see hashtag and channels above
@@ -32,7 +43,7 @@ In-progress
       - [ ] fast - all except peers known to be slow or unavailable
         REQUIRES: stats
   - [x] u | upload
-    - calls user-configured command to upload user's own feed file to their server
+    - calls user-configured command to upload user's own timeline file to their server
   Looks like a better CLI parser than "racket/cmdline": https://docs.racket-lang.org/natural-cli/
   But it is no longer necessary now that I've figured out how to chain (command-line ..) calls.
 - [-] Output formats:
@@ -45,9 +56,20 @@ In-progress
     - [x] mentions from timeline messages
       - [x] @<source.nick source.url>
       - [x] @<source.url>
-    - [x] "following" from timeline comments: # following = <nick> <uri>
-  Rough sketch from late 2019:
-
+    - [ ] "following" from timeline comments: # following = <nick> <uri>
+      1. split file lines in 2 groups: comments and messages
+      2. dispatch messages parsing as usual
+      3. dispatch comments parsing for:
+        - # following = <nick> <uri>
+        - what else?
+  - [ ] Parse User-Agent web access logs.
+  - [-] Update peer ref file(s)
+    - [x] peers-all
+    - [x] peers-mentioned
+    - [ ] peers-followed (by others, parsed from comments)
+    - [ ] peers-down (net errors)
+    - [ ] redirects?
+    Rough sketch from late 2019:
         let read file =
             ...
         let write file peers =
@@ -89,6 +111,30 @@ In-progress
 
 Backlog
 -------
+- [ ] Support date without time in timestamps
+- [ ] Associate cached object with nick.
+- [ ] Crawl downloaded web access logs
+- [ ] download-command hook to grab the access logs
+
+    (define (parse log-line)
+      (match (regexp-match #px"([^/]+)/([^ ]+) +\\(\\+([a-z]+://[^;]+); *@([^\\)]+)\\)" log-line)
+        [(list _ client version uri nick) (cons nick uri)]
+        [_ #f]))
+
+    (list->set (filter-map parse (file->lines "logs/combined-access.log")))
+
+    (filter (λ (p) (equal? 'file (file-or-directory-type p))) (directory-list logs-dir))
+
+- [ ] user-agent file as CLI option - need to run at least the crawler as another user
+- [ ] Support fetching rsync URIs
+- [ ] Check for peer duplicates:
+  - [ ] same nick for N>1 URIs
+  - [ ] same URI for N>1 nicks
+- [ ] Background polling and incremental timeline updates.
+  We can mark which messages have already been printed and print new ones as
+  they come in.
+  REQUIRES: polling
+- [ ] Polling mode/command, where tt periodically polls peer timelines
 - [ ] nick tiebreaker(s)
   - [ ] some sort of a hash of URI?
   - [ ] angry-purple-tiger kind if thingie?
@@ -100,13 +146,11 @@ Backlog
 - [ ] stats
   - [ ] download times per peer
 - [ ] Support redirects
-  - should permanent redirects update the feed somehow?
-- [ ] Support time ranges (i.e. reading the timeline between given time points)
+  - should permanent redirects update the peer ref somehow?
 - [ ] optional text wrap
 - [ ] write
-- [ ] timeline limits
-- [ ] feed set operations (perhaps better done externally?)
-- [ ] timeline as a result of a query (feed set op + filter expressions)
+- [ ] peer refs set operations (perhaps better done externally?)
+- [ ] timeline as a result of a query (peer ref set op + filter expressions)
 - [ ] config files
 - [ ] highlight mentions
 - [ ] filter on mentions
@@ -133,6 +177,13 @@ Backlog
 
 Done
 ----
+- [x] Crawl all cache/objects/*, not given peers.
+- [x] Support time ranges (i.e. reading the timeline between given time points)
+- [x] Dedup read-in peers before using them.
+- [x] Prevent redundant downloads
+  - [x] Check ETag
+  - [x] Check Last-Modified if no ETag was provided
+    - [x] Parse rfc2822 timestamps
 - [x] caching (use cache by default, unless explicitly asked for update)
   - [x] value --> cache
   - [x] value <-- cache