Re: "Fixing up" gnus - (how hard is this?). (was Re: (provide 'nnmaildir))

[prj@po.cwru.edu (Paul Jarc)]

Rob Browning <rlb@cs.utexas.edu> writes:
> So stepping back for a moment --- you've been working on an nnmaildir
> backend, right?

Right.  <URL:http://multivac.cwru.edu/nnmaildir/nnmaildir.el>.  (This
is a new URL; the old one will still work for a while too.  I'll also
get some documentation up there eventually.)

> As it stands now, what are the advantages/differences of that from
> nnmail?

Well, mail is kept in the maildir it was delivered to, to begin with,
so you don't have to worry about mbox From_ quoting, etc.  nnmail
backends can pull in mail from a maildir, but then store it
differently (but not all of them quote From_, of course).  See
<URL:http://cr.yp.to/proto/maildir.html>.  I haven't measured, but I'd
expect nnmaildir to compare well speedwise.  Each message is in a
separate file, and it generates a NOV line when a new message is first
seen, so it should be comparable to nnml.  While the server is open, a
structure is kept in memory, that holds the NOV lines associated with
each article; they're read from disk only at startup.  Files are never
rewritten, unless you edit an article, so the file's last-modified
time gives you the delivery time.  (Modulo an unsolved bug in
-request-{move,accept}-article.)  The file that stores group
information, including NOV lines, is written frequently and reliably -
the file ".nnmaildir" always exists (after it's been written once) and
it's always consistent.  I'm not very familiar with the nnmail
backends, so I'm guessing where the differences are, somewhat.

No splitting.  (This is probably the big reason that nnmaildir doesn't
inherit from nnmail.)  Each maildir is a group.  Assuming you use
qmail with maildir delivery, it's easy to direct message to the
appropriate maildir in the delivery process via .qmail files.  Mailing
list subscriptions are especially easy: as user prj, I control all
prj-anything addresses along with prj itself, so I subscribe prj-ding
to this list, and that address gets its own delivery instructions,
directing messages into my ding maildir.

The next version will store marks, in such a way that you should be
able to use other maildir readers on the same maildir between Gnus
sessions, and the two will see (some of) each others' marks.
(Assuming the other reader uses the "2," info format described in the
link above - I don't know if there are any such readers.)

> I'm wondering if we might be able to work together to document the
> backend interface better,

I'd especially like to see documentation of what triggers each backend
function, and what assumptions, if any, they can make about their
environment - current buffer, etc.


paul