Re: (provide 'nnmaildir)

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

On 14 Jul 2000, Paul Jarc wrote:

> - 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 think doing the NOV thing is important to gain speed.  The Gnus
backend interface heavily relies on the data contained in NOV lines,
and there are quite highly optimized functions for dealing with NOV
lines.

nnimap has code for retrieving header data from the IMAP server and
then caching this data in NOV format on the local disk.  Maybe that
kind of approach would work for you, too?  The first time you enter a
group, you gather NOV lines for all messages, and on subsequent visits
you just read that cache file.

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

Yes, article numbers must be monotonically increasing.  I you use a
NOV cache as described above, you could put the article numbers into
that file.  You could also store the maildir file name in the NOV
cache, and then you could get a list of files in the directory and a
list of file names from the NOV cache, and compare.  This would help
you find NOV lines for the new messages, and it would help you delete
stale lines from the NOV cache.

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

Gnus gets real mad when the article numbers are reset.  This is a weak
spot.  Gnus has not been designed for this.

You can use M-x gnus-group-clear-data RET and/or
gnus-group-clear-data-on-native-groups to make Gnus forget all article
numbers.  This means that all messages will be considered new, unread.

> The server argument to the backend functions is the second element
> of the select method, right?

I don't think so.  It just identifies a server.  There are two ways to
identify a server.  One way is to use a string, which is treated like
a name and then looked up in the list of all servers.  The other
possibility is to have a complete server definition, along the lines
of (nnml "frumple" (nnml-get-new-mail nil)), ie with server parameters
and all.

Luckily, it appears that you don't have to think about all this stuff
-- you can just use nnoo-change-server and then access local
variables, or stuff like this.

Hm.

Hmmm...  I have written a backend which seems to work, and I still
don't know what that server argument really means.  It appears that
nnoo is your friend, because it means you don't have to know all the
gory details.

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

Well, you could assign to it some meaning.  But I think it would be
better to just treat it as a name.  This way, users can decide what
their group names look like.

You see, if you specify (nnmaildir "frumple" ...) as a server
definition, then you will have group names like
nnmaildir+frumple:foo.bar.  If you specity (nnmaildir "" ...), ie an
empty server name, then the groups are named nnmaildir:foo.bar.

By `name' I mean that what you enter after a `B m' prompt, for
example.

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

I wish I knew...

> Can I see a concrete example of what a real-life NOV line would look
> like, as written to nntp-server-buffer?

Lessee:

1	Username/password for submission of ECDL paper	Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=)	28 Apr 2000 16:17:50 +0200	<vafzoqewbqp.fsf@lucy.cs.uni-dortmund.de>		160	7	Xref: lucy.cs.uni-dortmund.de conf.y2000.ecdl:1	To: ecdl2000@bn.pt	

These are tab-separated fields.  The first field is the article
number, the second field is the Subject header, then comes the From
header, then the date, then the message id, and I'm not sure about the two
numbers 160 and 7.  Then comes the Xref header (I'm not sure what that
means), and the remaining fields can be any headers from the message.
(See gnus-extra-headers and nnmail-extra-headers for the remaining
fields.)

But this format is surely described somewhere in the Gnus info file?

> Can I get away with using article numbers for references there?

Gnus identifies messages by their numbers.

> Why does gnus-nov-is-evil exist?  Obeying it might be mildly
> troublesome/expensive.

Yes.  But if the user wishes to do that...

> Does the `chars' field include the whole message, or just the body?
> `lines' is just the body, right?

Err...

> 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 think Gnus will barf if the backend doesn't support article numbers.
Maybe it's sufficient to just signal an error for message ids.

kai
-- 
I like BOTH kinds of music.