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

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

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sun, 06 Oct 2002, Kai.Grossjohann@CS.Uni-Dortmund.DE wrote:
>> 
>> 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".

That's a good idea, actually.

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

Right.

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

No, with the suggestion "native:foo.bar" would be a new-style line
whereas "foo.bar" would indicate an old-style line.

Anyhow.  All these methods are certainly viable methods.

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

Yeah, I was thinking of just transferring new entries.  The current
implementation only does three operations on the cache: (1) append an
item (at the end), (2) delete items from the front, and (3) search
items in it.

So just posting a message in a special group with the data in the
subject or something like that would do the trick.  But it would be
quite inefficient.

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

That's a good idea.

> Any other storage of the cache would need support on the IMAP
> server, AFAIK.

Yes.  I was hoping for some additional kind of protocols that IMAP
servers are likely to speak.  (Just as they now speak Sieve for
another purpose.)

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

Simplicity of implementation is a good thing, of course.

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

I don't think so.  Thanks for your hints.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)