Re: `gnus-unseen-mark' everywhere

[prj@po.cwru.edu (Paul Jarc)]

Simon Josefsson <jas@extundo.com> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> ["seen"] doesn't have to do with the backend itself, but it does
>> have to do with what is stored via the backend - i.e., the
>> articles.  OTOH, "cache" has to do with information always stored
>> outside the backend.  There's nothing outside the backend that
>> "seen" depends on, or must be synchronized with, etc.
>
> You could say that ".newsrc.eld" is outside of the backend and the
> seen mark depends on it and is specific to .newsrc.eld.

Depending on the user's configuration and wishes, it's possible that
the backend could have a more up-to-date copy of the "seen" marks than
.newsrc.eld does[*], so it makes sense to store "seen" in the backend
and allow the backend to update Gnus's "seen" marks.  This cannot be
said for "cache"; the backend does not store the cache itself, and so
its copy of those marks (were they to be stored in the backend, which
of course they aren't) will never be more up-to-date than Gnus's copy.
So there's no reason for the backend to update Gnus's copy, and thus
no reason for the backend - any backend, regardless of its
capabilities - to store "cache".

[*] You would probably say that the most up-to-date copy of "seen" is,
by definition, always in .newsrc.eld.  But note two facts:
- "seen" does not carry very much meaning for Gnus (less meaning than
  is carried by, e.g., "expire"); it is displayed in the *Summary*
  buffer, and it is automatically set for new articles.  That's all.
- Gnus does not make it easy for the user to define arbitrary new mark
  types.
As a consequence of these two facts, a user might want to adjust the
meaning of "seen" in such a way that the backend could have the most
up-to-date copy.  I think it would be nice if it weren't too hard to
do this.  But it would be even better to allow arbitrary new
user-defined mark types.  So I guess focusing on "seen" is the wrong
way to go anyway.

>> I think such a project could also handle the de-mark-ification of at
>> least "cache" and "download", right?
>
> That could be another step in that project.  It is probably best to
> unify the agent and the cache without touching marks first though.
>
> Maybe we should start porting Gnus to Guile and clean up the design in
> the process. But this sounds like really more work. :-)

Well, "cleaning up the design" sounds like it could easily include the
cache/agent unification as well. :)


paul