Re: Possible bug in nnml code

Re: Possible bug in nnml code

[Kai Großjohann]

Jan Rychter <jan@rychter.com> writes:

> Am I right in thinking that nnml-request-rename-group doesn't do
> anything about information stored in the nnmail cache, so if I use
> nnmail-split-fancy-with-parent, strange things will happen after group
> renaming?

You're right.  Have you got an idea how to fix it?
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Possible bug in nnml code

[Ted Zlatanov]

On Fri, 06 Dec 2002, jan@rychter.com wrote:
> The general idea is to:
> 
> 1. Rewrite the nnmail-cache-* functions somewhat:
> 
>   -- they should be able to operate on multiple groups per article
>      (to support crossposts),
> 
>   -- one should be able to implement nnmail-cache differently (in my
>      case, I am working on an SQL-based implementation and it seems
>      to work pretty well so far).
> 
>   I am not sure if that calls for taking them out of nnmail.el and
>   calling them something else. The name 'cache' is misleading.

That sort of goes along with the gnus-article-cache.el idea I was
talking about, except you don't like the name 'cache.'  I don't care
about the name one way or the other, as long as the code does what I
want :)

I think for crossposts you have to pick just one group out of the
bunch (the first one?) and stick with it.  Otherwise things will get
complicated very quickly.

The SQL implementation is OK if it's modular, but I think 99% of the
Gnus users will prefer a plaintext-file-based solution.  It's much
easier to maintain and debug, and will probably run faster once the
cache is loaded in memory.  So maybe we should just do a plaintext
cache file for now, and add SQL later.

> 2. Provide callback functions like nnmail-cache-notify-article-moved
>    and nnmail-cache-notify-group-renamed. The latter is redundant in
>    case of nnml, as nnml seems to know exactly which articles from
>    which group to which group it wants to move -- but it might be
>    necessary for other backends and it might allow for some
>    interesting optimizations.
> 
>    The backends would be required to call those functions when
>    moving articles between groups or when renaming groups.
> 
>    Currently when you move articles between nnml groups,
>    nnmail-cache gets updated by calling nnmail-cache-insert from
>    nnml-request-accept-article, so the
>    nnmail-cache-notify-article-moved function seems redundant. But
>    if we want to support multiple groups per message it becomes
>    important -- you need to know exactly from which group to which
>    group a message is moved to update the database.

I think there are appropriate hooks we can use, so iff users load
gnus-article-cache.el will those callback functions will be invoked.
Otherwise, no extra work should be done.  For nnmail.el those
callbacks are needed so it will load gnus-article-cache.el, but for
nntp.el for instance they don't make sense because you can't move an
article into nntp or rename an nntp group.

Ted

Re: Possible bug in nnml code

[Kai Großjohann]

Jan Rychter <jan@rychter.com> writes:

> The general idea is to:

Sounds like the right thing to do.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Possible bug in nnml code

[Lars Magne Ingebrigtsen]

Jan Rychter <jan@rychter.com> writes:

> The general idea is to:
>
> 1. Rewrite the nnmail-cache-* functions somewhat:
>
>   -- they should be able to operate on multiple groups per article (to
>      support crossposts),
>
>   -- one should be able to implement nnmail-cache differently (in my
>      case, I am working on an SQL-based implementation and it seems to
>      work pretty well so far).

Sounds like a good idea, except for the SQL part.  :-)  That'll limit
the usefulness for other users quite heavily.

And, yes, the name "cache" is quite confusing.  Perhaps something
like "registry" or the like would be clearer.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen