[PATCH] TODO: remove done items, add some more

[PATCH] TODO: remove done items, add some more

[Eric Wong]

It never ends...
---
 TODO | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/TODO b/TODO
index 2d20bad..9f58342 100644
--- a/TODO
+++ b/TODO
@@ -21,8 +21,6 @@ all need to be considered for everything we introduce)
   yet storing large amounts of data on computers without a
   public IP behind a home Internet connection.
 
-* TLS support for various daemons (including STARTTLS for NNTP and POP3)
-
 * optional Cache::FastMmap support so production deployments won't
   need Varnish (Varnish doesn't protect NNTP, either)
 
@@ -105,5 +103,8 @@ all need to be considered for everything we introduce)
 
 * support hooks, since low-level git-fast-import does not run them
   https://public-inbox.org/meta/20190405174329.GA21472@chatter.qube.local/
+  (note: may not be needed since we do grokmirror manifest.js.gz, now)
 
-* investigate native grokmirror support/integration
+* consider using HTTP::Date instead of Date::Parse, since we need the
+  former is capable of parsing RFC822-ish dates, used by Plack, and
+  the latter is missing from OpenBSD and maybe other distros.
-- 
EW

HTTP::Date replacing Date::Parse [was: TODO: remove done items, add some more]

[Eric Wong]

> +* consider using HTTP::Date instead of Date::Parse, since we need the
> +  former is capable of parsing RFC822-ish dates, used by Plack, and
> +  the latter is missing from OpenBSD and maybe other distros.

Ugh, HTTP::Date will try to use Time::Zone under the hood if
available for non-conformant dates.  And Time::Zone is part of
the same TimeDate package as Date::Parse, which I was trying to
stop depending on...

At least one incompatibility I've found is the inability of
HTTP::Date to handle the "+1" (yes, single digit) timezone
offset which we have a test case for in t/msgtime.t

There's probably a few more wacky historical cases which we lack
test cases for.  Hell, there's even a case of 3-digit years in
LKML history which we special-case for.

So, I'm not sure it's worth it...  The good thing is that going
forward, dates seem to much more conformant as clients got
better.  So there's only a finite set of historical special
cases which we'd need to deal with.