view TODO @ 188:f1bacee93ca6 noffle

[svn] * src/client.c,src/client.h,src/fetch.c,src/noffle.c,src/server.c: robustness - instead of retruning simple Passed/Failed statuses from connection functions, return an integer status instead. This allows Noffle to distinguish between a connection failure, an unrecoverable protocol error and a recoverable problem. As a concrete instance, Noffle will no longer abort the connection if a group is removed from the upstream server. Also beef up error detection a bit. * src/content.c: instead of overwriting the existing content file(s) when updating - which leaves a window where Noffle is vulnerable to failure which will leave the content file corrupted (yes, it happened to me), write a new content file and rename it over the old file only when it has been written and closed with no errors reported.
author bears
date Wed, 12 Sep 2001 21:33:44 +0100
parents fed1334d766b
children 24d4cd032da5
line wrap: on
line source

-------------------------------------------------------------------------------
NOFFLE Todolist
-------------------------------------------------------------------------------

Urgent
------

 * Has Client_connect resource leaks if it fails?

Later
-----

 * Improve performance of group database. Using GDBM is a bad choice,
   better use a btree from the Berkeley db library in libc.
   This will be a good time for a redesign of the group.h interface
   with respect to process concurrency if the simple global locking strategy
   will be changed in the future.

 * Add "hostname" config option for setting the FQHN in generated message IDs.

 * Read timeout when running as server and automatically close if client
   does not send data for a longer time.

 * Implement simple filter using popen or fifos.

 * Make compatible to latest NNTP draft.

 * Improve speed of online mode: Keep connection to server open for a while

 * Check all in
   http://mars.superlink.net/user/tal/writings/news-software-authors.html
   (Use NOV library? Use inews for validating posted articles? ... )

 * Store requested articles by group + number. This would allow to create
   pseudo-groups (like <groupname>.requested) that contained only fully
   downloaded articles in overview mode (very nice and clever
   idea sent in by a user, it would make using overview mode much easier).
   Second advantage: Noffle would work with servers that have retrieving
   articles by message-id disabled.

 * Expire should clean up empty request/outgoing directories, so they will not
   exists forever after a server change.

 * Do not log program abortion due to SIGINT, if no inconsistency can occur,
   (e.g. when calling 'noffle -d' to a pipe and next program terminates or
   pressing ^C). 

 * Improve www page and documentation.

 * Keeping the content list for several lock/unlock times could lead to
   inconsistent results, because content list is maybe modified by
   pseudo articles. Check this!

 * Optimize NEWGROUPS (extra list?)

 * Add noffle query option for checking all groups, if they are still
   available at the remote server(s) and delete them otherwise.

 * In online mode, retrieve full article header from remote server if client
   sends a HEAD command. Presently, only the header lines from the overview
   are returned and the article is only retrieved on an ARTICLE or BODY command.
   The reason for this was that some readers (like pine) retrieve the group
   overview by sending lots of HEAD commands and their performance would badly
   suffer. On the other hand, some readers (like slrn) cache the header from
   a HEAD command, even if a following ARTICLE command gets more header lines,
   so that not all header lines are available when reading news in online mode,
   before the next start of the reader. But some header lines (e.g. Reply-To)
   are important.
   Maybe make the behaviour configurable.


User-Wishlist
-------------

 * Group requesting: I'd like noffle mantain a whitelist of users who can
   request new subscriptions: for instance, if user mardy wants noffle to
   fetch headers of it.comp.os.linux, he could just post a message to
   noffle.control with something like this in the body:                                                     	 
   subscribe-over: it.comp.os.linux                 	 


Some day far away
-----------------

 * Understand supersedes header (useful for reading news.answers group)

 * Get and execute cancel messages (read control.cancel, but use xpat to get
   only cancels for groups in fetchlist). Seems to be expensive (20000 headers
   a day, takes the remote server to search through)