Re: Do nnmail-split-fancy-with-parent for nnimap?

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 06 Oct 2002, Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:
>> Why not store the group name as Gnus shows it, e.g. when moving
>> articles?  nnxyz+abcdef:groupname is what I'm thinking of.  Then
>> the unqualified groups are in the primary backend - as they would
>> be if you manually moved articles around.  I'm talking as a Gnus
>> user, maybe the implementation is much more complex that way.  I
>> don't know the internals of mail moving.
> 
> The problem is backward compatibility.  Suppose people have nntp as
> their primary server, and nnml and nnimap as secondary servers.
> Then right now foo.bar means the group nnml:foo.bar (because nnml is
> the "primary mail backend"), but your suggestion would change it to
> mean a group on the nntp server.

Right, so the problem is that right now, the cache assumes nnml.  You
could have a cache version at the top of the file (like BBDB), and
upgrade users to the newer cache version when they run the new
function, rewriting every group name to "nnml:groupname".

Or you could have a file called .nnimap.cache, separate from the nnml
cache.

> (One possibility would be to make all groups be prefixed, maybe
> we could use "native" for the primary server.)

That's what I was thinking, but realize that the "native" prefix or
whatever we use for the primary server is superfluous - if it's an
arbitrary string, you may as well skip it.

>>> It would be really cool if ~/.nnmail-cache was stored on the
>>> server somehow.  Is there a way to store data like this alongside
>>> IMAP mail on a server?
>>
>> I think the network usage would be too high for this.
> 
> You must be kidding.  Right now, nnimap splitting transfers each
> message over the net twice (one fetch from nnimap:INBOX, one put to
> the target group).  I don't see how it can hurt to add 60 or 80
> bytes to this traffic.

> (It conceivable that .nnmail-cache must always be transferred in
> full, maybe via ange-ftp.  This is a bad solution indeed, and for
> this your counter argument would be right.  I wasn't even
> considering such bad solutions before you mentioned the possibility
> :-)

You would have to either break up the cache in some way, or transfer
the entire cache every time.  You can store the cache in a group
(e.g. "gnus-imap-split-cache") that would basically be a mail group
like any other; corruption of its data is the user's problem.  Any
other storage of the cache would need support on the IMAP server,
AFAIK.

Now, if you transfer the entire cache, the chance of data corruption
is smaller, and the code is much simpler.  That's the solution I
thought of, initially.

Breaking up the cache in some way would complicate the code
considerably.  Also, you would have to devise an efficient way to
search all the cache elements for an article ID, or have the subject
of each article in the cache group somehow contain the article ID.

Either way, with a single cache, or with a piecemeal cache, it's a lot
of traffic when your cache grows to 50000 articles.

Am I missing something obvious?

Ted