Re: nnima-split-with-parent

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I want nnimap-split-with-parent! :) 

Me, too.  A simple way to get it is to frob
nnmail-cache-primary-mail-backend so that it returns your nnimap
backend.  But this invalidates previous lines in .nnmail-cache.

> I was looking at the nnmail-split-with-parent code, and I see that the
> nnmail cache is used for duplicate detection *and* for splitting with
> the parent.  So it's not easy to abstract the nnmail cache as it is to
> arbitrary newsgroup names, we might get erroneous warnings about
> duplicates.  I think the format for the "new" article-ID cache should
> be
>
> backend-name\tarticle-ID\tgroup-name
>
> We can keep the current nnmail cache as well, but this format can
> replace the old cache format with very little work.  Maybe we can copy
> and fix up the new-cache from the old nnmail-cache if we're upgrading,
> and otherwise always use the new-cache file?

This is a very good plan.  I've been thinking hard to change the
.nnmail-cache format in an upwards-compatible way, but I think your
suggestion is better: replace the nnmail-cache implementation with a
new one that just reads and converts the old file, if necessary.

Just for reference, the upwards-compatible format change would be as
follows.  Right now, there are some lines with just msg-id in it.
Some have msg-id, then tab, then group name.  The change would be to
add lines with msg-id, then tab, then group name, then server name.

If the group name is given but the server is missing, then assume
it's the server returned by nnmail-cache-primary-mail-backend.

For new lines, we might want to always write the server name.  Write
"native" for the native server.

But this is just for reference, I think your solution is better.

> We should separate the functionality into gnus-article-cache.el if
> it's going to be generalized (or whatever the file is called).
>
> Functions affected (new names are not necessarily final):
>
> nnmail-cache-insert: needs to be generalized to
> gnus-article-cache-insert, maybe figuring out the backend name instead
> of having it passed in for minimum code changes?

nnmail-cache-insert already knows the group I think.  It can intuit
the server from there.  (It currently does I believe.)

Oh, it uses gnus-command-method instead.

> nnmail-cache-fetch-group: needs to be generalized to
> gnus-article-cache-fetch-group, and the logic altered a little to
> allow for the backend name at beggining of line.  Like the insert
> function, maybe it should figure out the current backend name instead
> of having it passed in for minimum code changes?

Yes.  gnus-command-method.

> nnmail-cache-id-exists-p: generalize to
> gnus-article-cache-id-exists-p, unchanged otherwise
>
> the other nnmail-cache-* functions should be easily migrated to
> gnus-article-cache-*
>
> I hope someone is interested in doing this or at least giving me some
> feedback...

I'm afraid I don't have time, but I'm happy that *you're* interested :-)
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)