
definataly gonna do:
*use write-flush-rename for midinfo/headers/config(if we ever modify it)
*make manpage for ngetlite
*make MID_INFO_MIN_KEEP, etc config options
*update STL includes/etc to use new non-.h files, and std namespace
*fix EINTR (should try read again, not err (also should keep the same timeout within multiple tries?))
*add log output ability
*fix tempfiledir mixup where -w to write doesn't use the tempfile dir and such misses parts we already have
*make ngetlite skip downloading parts we already have (but which are still listed as not gotten in the listfile)
*test libc5/old gcc (forget it.  ngetlite is their only hope. upgrade.)
*make it store the path to store in the retrieve queue, so that we wouldn't have to 
  delete cache/retrieve files/reload cache/repeat for every dir change


might do eventually:

 * make -@ relative to start dir rather than -p dir? (when not using .nget3/lists/ dir)
 * allow -p/-P to create dirs (ala mkdir -P).  Perhaps enabled by config option
   or other switch?
 * per group (.ngetrc) config setting for "base directory", then -p/-P could be
   relative of that.  (or not... maybe if you put / or ./ in front, it would be
   relative to current instead of base)
 * allow searching based upon date/author/lines etc.  ideally, something like:
   nget -r (date > 03/04/1999 && (author = bob && subject = file\.) || (subject
   = blah)).. DONE, but uses postfix method.. might be nice to add infix type.
 * check for existance of files, don't d/l what we have already (overridable?)
	use substring match to select filename? (ie: -r "heres the
	files:.*(snarf\.r..) ").
	or try some sort of parsing?  prolly really hard to get right for all
	(even most) cases possibly could do a glob, then search through the
	headers with the file names.. come at the problem from reverse - done
	the reverse way.. seems pretty successful, though it doesn't stop from
	d/l'ing multiples of the same file.. could be adapted to such though,
	by adding files to a similar list after they are d/l'd and we know
	their names.

only considering:

 * store fileread info in a seperate file, so we don't have to write out the
   big ole cache again. -- partially done, just need to implement
   saving/loading/checking/adding ... DONE... but should we store only the anum
   of the first part, like now, or all of the anums? (anums -> message-ids)


Misc info:
rfc977	"Network News Transfer Protocol"
rfc1036	"Standard for Interchange of USENET Messages"
various other rfcs/drafts: http://www.tin.org/docs.html
