newsrc stored with Tramp or IMAP (was: Gnus: Buffer has a running process; kill it? (y or n))

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 14 Oct 2009 10:16:34 +0200 Vegard Vesterheim <vegard.vesterheim@uninett.no> wrote: 

VV> I could configure all my Gnusae to store its newsrc files with tramp
VV> (possibly over IMAP), and configure one of them to be master and the
VV> others to be slaves.

VV> Would this work without having to restart Gnus whenever I want to read
VV> mail?

No, Gnus wouldn't know that the other instance has modified the newsrc
file, and it wouldn't be able to easily synchronize changes with the
modified version.

The Tramp solution is good for cases where the file is small and
self-contained.  Unfortunately the newsrc file has too many dependencies
on things in memory.

I think the proper solution will be to allow saving and reading the
newsrc file in a more structured way, by group name.  Basically just
gnus-newsrc-alist needs to be broken up.  All the other variables
(gnus-topic-topology, gnus-topic-alist, gnus-server-alist, etc.) can be
stuffed into a single entry.  gnus-newsrc-file-version can be used to
indicate this more structured newsrc file.

With the imap-hash library I uploaded recently, this is pretty easy.
You'd have one entry per group name, plus one "global" entry.  To see if
the entry has been updated, you'd check the message date and compare it
to your own (so you'd need to track the last update of a group from the
newsrc, similar to how gnus-newsrc-last-checked-date works).  Merging
marks and counts per group is much easier than merging globally.

This work can obviously be generalized to use any storage mechanism,
from a remote RDBMS to a non-relational database like CouchDB or
Cassandra to Amazon's S3.  Furthermore, other Gnus structured data can
use it: score files, splitting rules, and the registry.  So I think it's
worth pursuing.  On my own, I'd probably get to it sometime next year
but if someone else is interested please feel free...

Ted