Syncing gmane group read state across multiple gnusen

Syncing gmane group read state across multiple gnusen

[Steinar Bang]

Right now I have three different Gnus clients that read the same IMAP
mailboxes, different non-gmane newsreaders and groups, and finally an
overlapping set of gmane groups.

What I would like to do is to synchronize the read state for the gmane
groups that are read on all gnus installations.

Does anyone else have a similar use case?  Does anyone have a solution?

The matches that google has found me is complete synchronization of
multiple Gnusen, but that's not what I found.  And the solutons I've
seen has been sort of hacky.

I guess I'm looking for an explicit export and import of gmane group
article read state...  A bit of automation around that would be
nice, but not essential.  It will in any case be easier than wading
through the articles once more.

Re: Syncing gmane group read state across multiple gnusen

[Duncan]

Steinar Bang <sb@dod.no> posted u3a9y9bh0.fsf@dod.no, excerpted below, on 
Thu, 18 Jun 2009 10:45:31 +0200:

> Right now I have three different Gnus clients that read the same IMAP
> mailboxes, different non-gmane newsreaders and groups, and finally an
> overlapping set of gmane groups.
> 
> What I would like to do is to synchronize the read state for the gmane
> groups that are read on all gnus installations.
> 
> Does anyone else have a similar use case?  Does anyone have a solution?
> 
> The matches that google has found me is complete synchronization of
> multiple Gnusen, but that's not what I found.  And the solutons I've
> seen has been sort of hacky.
> 
> I guess I'm looking for an explicit export and import of gmane group
> article read state...  A bit of automation around that would be nice,
> but not essential.  It will in any case be easier than wading through
> the articles once more.

Does Gnus use the standard newsrc format?  If it does, then what you're 
asking should be a breeze, because the newsrc files are by definition 
single-server only already.  Thus, it would seem a natural fit for 
tracking status on a single shared server when others aren't shared, just 
find the appropriate newsrc file for each one and share it, leaving the 
others alone.

I don't use gnus so can't say, but know that pan works this way, using a 
single newsrc file for each server it tracks.  It's thus quite easy to 
share the same single-server tracking among different machines and 
clients, just share the same newsrc but leave others alone.  That can be 
accomplished using symlinks or editing the servers.xml file for each so 
it points to a singe common newsrc file.

If gnus doesn't use newsrc files, then...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Syncing gmane group read state across multiple gnusen

[Steinar Bang]

>>>>> Duncan <1i5t5.duncan@cox.net>:

> Does Gnus use the standard newsrc format? 

Yes and no.  It writes a .newsrc file for its primary NNTP server, but I
don't know if, and if so: when, it reads it.

It persists all of its other state in a monster lisp file called
.newsrc.eld.

> If it does, then what you're asking should be a breeze, because the
> newsrc files are by definition single-server only already.  Thus, it
> would seem a natural fit for tracking status on a single shared server
> when others aren't shared, just find the appropriate newsrc file for
> each one and share it, leaving the others alone.

Right.  If I switch primary NNTP server, that isn't gmane today, _and_
if Gnus can be persuaded to actually read the .newsrc file, then this
should be possible.

One possible downside of this, is that I don't think I can switch the
primary NNTP server, without losing the current read state on both
gmane, and the server that is currently the primary NNTP server.

> I don't use gnus so can't say, but know that pan works this way, using a 
> single newsrc file for each server it tracks.  It's thus quite easy to 
> share the same single-server tracking among different machines and 
> clients, just share the same newsrc but leave others alone.  That can be 
> accomplished using symlinks or editing the servers.xml file for each so 
> it points to a singe common newsrc file.

> If gnus doesn't use newsrc files, then...

Well, thanx for the idea.  It seems simpler than my vague thoughts about
server read state exports and imports.

Re: Syncing gmane group read state across multiple gnusen

[Dave Goldberg]

> Well, thanx for the idea.  It seems simpler than my vague thoughts about
> server read state exports and imports.

I read IMAP and a couple nnrss feeds from Gnus in three places at
work, my primary laptop, which runs linux, a Windows XP VM (cygwin) on
that same laptop, and on a shared Unix (various flavors, many
machines, some generated somewhat on the fly) environment.  In the
latter case, my home directory is in an AFS directory so the Gnus dot
files are shared.  I just have to be careful to run gnus-slave if I've
got multiple instances going.  I use unison to sync the dot files with
the other two home directories.  I typically don't try to do merges
when there are conflicts, though.  I just take the one with the most
recent timestamp.

-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Syncing gmane group read state across multiple gnusen

[David Engster]

Steinar Bang <sb@dod.no> writes:
>>>>>> Duncan <1i5t5.duncan@cox.net>:
>
>> Does Gnus use the standard newsrc format? 
>
> Yes and no.  It writes a .newsrc file for its primary NNTP server, but I
> don't know if, and if so: when, it reads it.

It reads it if gnus-read-newsrc-file is t (the default).

If will read if *after* it has read .newsrc.eld, so it should update the
read articles from .newsrc, but I never tested this. Other information
(ticked articles, killed groups, foreign/secondary methods, etc.) are
only stored in newsrc.eld, of course.

>> If it does, then what you're asking should be a breeze, because the
>> newsrc files are by definition single-server only already.  Thus, it
>> would seem a natural fit for tracking status on a single shared server
>> when others aren't shared, just find the appropriate newsrc file for
>> each one and share it, leaving the others alone.
>
> Right.  If I switch primary NNTP server, that isn't gmane today, _and_
> if Gnus can be persuaded to actually read the .newsrc file, then this
> should be possible.

Be aware that different servers usually have different article
numbers.

-David

Re: Syncing gmane group read state across multiple gnusen

[Steinar Bang]

>>>>> Dave Goldberg <david.goldberg6@verizon.net>:

> I read IMAP and a couple nnrss feeds from Gnus in three places at
> work,

(On a side note: IMAP isn't a problem.  It just needs a visit of the
nnimap group to sync up the read numbers.  All tick marks are on the
articles on the IMAP server)

> my primary laptop, which runs linux, a Windows XP VM (cygwin) on that
> same laptop, and on a shared Unix (various flavors, many machines,
> some generated somewhat on the fly) environment.  In the latter case,
> my home directory is in an AFS directory so the Gnus dot files are
> shared.  I just have to be careful to run gnus-slave if I've got
> multiple instances going.  I use unison to sync the dot files with the
> other two home directories.  I typically don't try to do merges when
> there are conflicts, though.  I just take the one with the most recent
> timestamp.

Right.

But this requires that I have the exact same group subscription on all
my Gnusen, doesn't it?

Or can slave files be read in, even if they refer to groups you don't
have, or don't refer to all of the groups you have?

If the latter is the case, then this is a plan.

Re: Syncing gmane group read state across multiple gnusen

[Steinar Bang]

>>>>> David Engster <deng@randomsample.de>:

> It reads it if gnus-read-newsrc-file is t (the default).

> If will read if *after* it has read .newsrc.eld, so it should update
> the read articles from .newsrc, but I never tested this. Other
> information (ticked articles, killed groups, foreign/secondary
> methods, etc.) are only stored in newsrc.eld, of course.

Ok.  Thanx for the information!

> Be aware that different servers usually have different article
> numbers.

Yes, but with Gmane, there is only the one server (or server cluster, or
whatever),

The only issue then would be that I have to switch the primary NNTP
server, and lose all of my current state, and I don't want that.

Or is it possible to make Gnus produce .newsrc files for other NNTP
servers than the primary one...?

Re: Syncing gmane group read state across multiple gnusen

[Vegard Vesterheim]

On Fri, 19 Jun 2009 13:03:03 +0200 Steinar Bang <sb@dod.no> wrote:

>>>>>> Dave Goldberg <david.goldberg6@verizon.net>:
>
>> I read IMAP and a couple nnrss feeds from Gnus in three places at
>> work,
>
> (On a side note: IMAP isn't a problem.  It just needs a visit of the
> nnimap group to sync up the read numbers.  All tick marks are on the
> articles on the IMAP server)

I think this is a problem, albeit a small one. It is mildly annoying
to have gnus report that a nnimap group has a given number of unread
messages, and then discover that this is in fact false upon visiting
the group. Especially if it turns out that there are *no* unread
messages to be found.

Hmm, maybe this initial visiting of all imap groups (to resync unread
counts) can be scripted/automated via elisp? That would at least
alleviate the problem somewhat.

 - Vegard V -

Re: Syncing gmane group read state across multiple gnusen

[Steinar Bang]

>>>>> Vegard Vesterheim <vegard.vesterheim@uninett.no>:

> Hmm, maybe this initial visiting of all imap groups (to resync unread
> counts) can be scripted/automated via elisp? That would at least
> alleviate the problem somewhat.

Should be doable.

I've also wanted to do something similar, but more advanced, on Gmane
groups:
 - visit the group
 - walk through all unread articles, and visit them, and then
  - if present, mark as unread and go to the next article
  - if expired (typically reported spam articles), skip to the next
    article 

What's kept me from doing it so far, is that the function for visiting
articles, seemed not very appropriate to run as a lisp function (can't
remember why or what, only that it wasn't obvious how I should use it).

Also, since this
 ;; Store article in agent when reading it while online
 (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)
no longer works to cache all read articles in agent, the nice side
effect of having cached _all_ articles in in a group, not just the ones
smaller than whatever cutoff size, isn't present