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

Urgent
------

 * Tidy data structure initialisation when posting (post.c).

 * Post: better checks on posted article (check for duplicate headers,
   address in From: headers).

 * Post: Only generate Reply-To: from From: if a configuration option set.

 * Deal properly with headers split over several lines where the overall
   content of the header exceeds MAXCHAR characters (i.e. length of Str).

Later
-----

 * Provide list of suggested configurations for popular upstream servers.

 * Review latest NNTP draft (http://www.ieft.org/ids.by.wg/nntpext.html).
   Noted so far: Implement DATE and OVER. OVER is a synonym for XOVER,
   which should continue to work for compatability reasons.

 * Review latest Usenet message format (draft).
   http://www.ietf.org/ids.by.wg/usefor.html.

 * 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.

 * 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.

 * 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
-----------------

 * Extend execution of cancel messages to those retrieved from the upstream
   server (e.g. by subscribing to control.cancel - only fetching cancels
   for groups in the fetchlist would be a good idea, volume in
   control.cancel).