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

[Rob Browning <rlb@cs.utexas.edu>]

prj@po.cwru.edu (Paul Jarc) writes:

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

So I'm not an expert on maildir, but as I recall it keeps articles in
three subdirectories of the main directory right, and one of those
subdirs is where all the new articles go, so for this backend,
figuring articles will be in different locations depending on their
state, or do you just treat the new article subdir as the spool dir
and immediately move the articles elsewhere when gnus checks for mail?

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

I'm not sure I know exactly what's in the NOV lines, but presuming
it's just article info, as long as you have some "safety-net" code in
there, this might even be safe in the context of multiple gnus
accessing the same group.  You'd just detect the changes the next time
you tried to access something that had changed...

> Files are never rewritten, unless you edit an article, so the file's
> last-modified time gives you the delivery time.

Is this an efficiency issue?  It seems a little risky.  If I tar up my
directory, and forget to use "p", or if the system clock is screwy, I
get the wrong answer, or is delivery time not something that's
normally in the article file?  An alternate approach would be to just
use caching of some flavor.  Store the date in a file in
groupdir/.nnmaildir (or whatever).

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

This sounds pretty good, but would it be helpful to make
groupdir/.nnmaildir a directory rather than a file?  We did that for
gnucash's user startup/config files, and it made keeping track of
things somewhat cleaner - separating state data from config data in
separate files, making parsing easier because the contents of each
data file can be more limited, etc.  FWIW.

> No splitting.  (This is probably the big reason that nnmaildir
> doesn't inherit from nnmail.)  Each maildir is a group.

So how/when does the user see new groups?  Do they have to manually
add each one?  It might sound crazy, but I had always kinda wanted a
backend that was more like dired.  I'd just see what's in the
(sub)tree and could manipulate things however I like, either from
gnus, or from the shell.  In that situation, you could either have a
manual update button to tell gnus to detect any changes (deleted/moved
groups), etc., or have gnus do the equivalent of a diff on "find
my-mail-tree -type d" every now and then to see if it needs to rescan.

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

Looking at the spec, this sounds good, though it might be nice to have
two files in the long run, one that stores the "2," format as it
evolves and another that's a superset of that so if you want to store
more info, info that other mailers can't necessarily understand, you
have somewhere to keep it out of harms way (in other words, the "2,"
file would be derived from the data in the superset file which would
probably be elisp/scheme forms).  Though I suppose you can worry about
that once you find something you want to put in the superset...

In any case, it sounds like when you do this, the data in .newsrc.eld
will be irrelevant for your backend.  Will gnus automatically prefer
the data in the backend to the .newsrc.eld file?

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

Yep.  It would be nice to have a well-documented interface (even if we
had to write a little bit of "adapter" code) that all of the backends
could be modified to conform to.  It would also be nice if things were
set up so that for similar backends, there was a smaller set of
functions that had to be written to create each one.  There might be a
set of default functions for things like article-state->form
form->article-state, etc.  You wouldn't have to use these, but you
could if/when you didn't need anything more tailored.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930