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 I'm not an expert on maildir, but as I recall it keeps articles in
> three subdirectories of the main directory right,

Yes: tmp/, new/, and cur/.  Messages are delivered by writing them to
new files in tmp/.  Once they're completely written, they get linked
into new/, and are then considered delivered.  MUAs look for new
messages in new/ and rename them into cur/.  nnmaildir does the
renaming in -request-scan, and doesn't mark an article as read or not
depending on whether it's in new/ or cur/.  It could get by just as
easily without moving articles at all.

> I'm not sure I know exactly what's in the NOV lines,

Article number, Subject:, From:, Date:, Message-ID:, References:,
number of characters in message, number of lines in body.

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

Not at present, but I think that will be true to some degree in the
future, as an accidental result of changes I'm planning.  The
information about the messages is checked at startup - the existence
of the file is verified - but after that, if a message gets deleted
from outside Gnus, and then you try to read it, you get an error, and
nnmaildir doesn't condition-case it.

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

It's a matter of treating message files as sacred.  Delivery times
could also be stored somewhere else, but they're never used in Gnus.

> is delivery time not something that's normally in the article file?

It isn't, although the mbox format adds it in the From_ line.

> This sounds pretty good, but would it be helpful to make
> groupdir/.nnmaildir a directory rather than a file?

I don't think so.  .nnmaildir contains two pieces of information about
the group (name and largest article number), and then it's one line
per message, containing the filename and NOV data.  Fairly
homogeneous.

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

At present, yes.  An nnmaildir select method looks like:
'(nnmaildir "server name" (nnmaildir-groups ("/path/to/maildir"
                                             "/path/to/another")))
and each maildir is a group.  But I think I'll change it to something
like this:
'(nnmaildir "server name" (nnmaildir-directory ("/path/to/dir")))
where /path/to/dir contains maildirs, or symlinks to them.  New groups
could be detected in -request-scan, and -request-create-group would
become possible.

> Looking at the spec, this sounds good, though it might be nice to have
> two files in the long run,

The "2," info is stored in the filenames themselves.  I plan to store
the 4 maildir marks there, and also all marks in .nnmaildir.
.nnmaildir will be updated when the server is opened to reflect
changes in marks made by a different mail reader, and files will be
renamed to reflect changes in marks made by Gnus, so those changes
will be visible to other mail readers.

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

The backend can provide a -request-set-info function, which will be
called to correct Gnus's notion of marks and such.

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

Moreso than nnoo allows, you mean?


paul