(provide 'nnmaildir)

[Paul Jarc <prj@po.cwru.edu>]

I'm writing nnmaildir.el so I can take full advantage of
qmail/maildir, and of Gnus.  (See <URL:http://cr.yp.to/proto/maildir.html>.)
I've fumbled along to the point where I can read messages (woohoo!),
but it's still pretty primitive (e.g., no groups yet), as I'm not
overly familiar with the Gnus backend interface, and some of the stuff
I've done will probably have to be thrown out/redesigned later.  I've
been developing on emacs 20.3 and Gnus 5.6.45.  (Has the backend
interface changed since then?)  Here's what I'm doing:

- The maildir will be a full-fledged backend, not just a source to
  gather mail from to be stored somewhere else.  I've seen in the list
  archives that that has already been done, but I say it subverts
  much of the design of maildir and loses many benefits.  So I'm using
  nnoo and nnheader, but not nnmail.  (I might be able to use some
  stuff from nnmail, but probably nothing that needs to know where
  messages are stored.)

- Message files will never be rewritten.  The data in the files and
  the last-modified times are to be treated as precious.  I've thought
  about encoding NOV lines in the filenames for easy access, but that
  might get a bit unwieldy.  (I do add Lines: when writing the full
  headers to nntp-server-buffer, but I don't write it back to the
  message file.)  I could just write the NOV lines to a separate
  per-maildir file, but that's so boring.  It'd complicate message
  deletion, too.

- I've been using the message files' inode numbers as article
  numbers.  It seems this won't be viable, though, since messages are
  sorted by article number in the summary buffer.  In
  nnmaildir-retrieve-headers, I tried doing my own sorting of the
  requested articles and writing the headers to nntp-server-buffer in
  chronological delivery order, but they got resorted. :(  Also, Gnus
  might get the idea that I've read articles 1-5000 just because I
  happened to read article 5000, which was the lowest numbered article
  at the time.  If a lower-numbered article arrives later, I won't see
  it.  (Sadly, this (or something similar) actually happens with my
  NNTP server.)  So I may have to generate article numbers some other
  way. :(

So... what conditions are article numbers supposed to satisfy?  What
do NNTP servers do when they run out (I'm assuming they don't use
bignums), and how does Gnus react?

The server argument to the backend functions is the second element of
the select method, right?  A string, typically?  And as the author of
the backend, I decide what it means?  (Right now, I'm using it to
specify the path to the maildir, but I think I'll create a backend
variable for that purpose instead.)

I'm unclear about the usage of nnoo-change-server and
nnoo-push-server.  I've just been working from (un/sparsely commented)
examples in the various nn*.el to guess where to use each.  If I
define a backend variable like (defvoo nnmaildir-maildir "~/Maildir/")
and use a select method like
'(nnmaildir "blah" (nnmaildir-maildir "/path/to/maildir")) then my
understanding is that nnoo-change-server will, among other things, pick
up the value of nnmaildir-maildir from the defs argument, and that
value will be visible to nnmaildir-open-server (i.e., the caller of
nnoo-open-server).  Is this right?  What about nnoo-push-server?

Can I see a concrete example of what a real-life NOV line would look
like, as written to nntp-server-buffer?  Can I get away with using
article numbers for references there?  Why does gnus-nov-is-evil
exist?  Obeying it might be mildly troublesome/expensive.  Does the
`chars' field include the whole message, or just the body?  `lines' is
just the body, right?

How does Gnus know whether a backend supports article identification
by article number ranges or Message-IDs?  I guess backends must fail
sensibly if they don't support these, hm?

I'm thinking of implementing groups via something like
nnmail-split-fancy.  I've also thought of having a backend variable,
say, nnmaildir-hierarchy, that all groups would be organized under.
I.e., if nnamildir-hierarchy were set to "mail", and a message was
determined to belong to group "foo", it would actually be put in
"mail.foo".  (I suppose I could use the server name instead of a
backend variable.)  Is this group name prefixing a bad idea?

I think those are all the issues I've run into so far, but I haven't
made a go at any of the optional backend functions yet, so I'm sure
I'll be back with more questions later.


paul