Re: TODO idea:

[Paul Franklin <paul@cs.washington.edu>]

>>>>> Jason R. Mastaler writes:

 > Is it necessary to write a new backend?  Why not just code the unseen
 > sequences functionality into nnmh and optionally, nnml?

Why code the unseen functionality?  Since nnmh isn't quite mh in that
it can't handle asynchronous delivery, there isn't any current code
(AFAIK) which adds messages to nnmh or nnml folders and updates the
unseen sequence.

So, there needs to be another way.  One way would be to have a file
similar to the active file which the mail delivery system writes to;
nnml would only read it and update its own active file based on what
it reads.  The mail delivery system would still have to lock it, but
nnml no longer cares how.

The other way is the method I keep making noises about implementing
but never get my act in gear and implement it.  Let the messages be
delivered directly into nnml folders based on the active file.  Then
keep key headers (for the overview) and add one saying what folder &
nessage number the message was placed at to the normal locked mail
spool.  So now our old trusted mail spool only has headers needed for
overview generation instead of the entire message, and gnus only has
to write active and overview files, not the contents of every message.

(Then all you do is cache the overview lines until group entry instead
of writing them immediately, and writing the unseen handler becomes
easy.)

Either one of these requires both gnus/nnml and the mail deliverer to
back off if it selects a folder's next message number and creating the
file fails, as that means the other just grabbed it.

One of these days...

--Paul