Re: gnus sync

[Steinar Bang <sb@dod.no>]

>>>>> Steinar Bang <sb@dod.no>:

> I've had some thoughts about the implementation myself.  I've been
> thinking of a RESTful approach.

Some thoughts on gnus behaviour:

I think that on startup it would be best to build up a complete
".newsrc.eld" in memory, that is the combination of the ~/.newsrc.eld on
disk, and what is received from the server.  If the server can't be
contacted (ie. if using the agent), then only the ~/.newsrc.eld comes
into play.

This means that when saving the .newsrc.eld, one is saving the
combination of what has been done locally and what has been received
from the server.

This means that merging of server and client information all the way
down to the tick marks, have been done, before starting to read news.

There should be a "last synchronized" time stamp in the .newsrc.eld, and
when polling the server it should relate everything against that (it
might be that there needs to be more fine-grained sync timestamping in
the .newsrc.eld, but I suggest just going with the single timestamp
initially).

When getting the backend list, use conditional GET against the time
stamp, and if you get a 304 not modified, then .newsrc.eld is the master
in conflicts, ie. differences in the number of backends.

Adding backends is easy and conflictless, but DELETE of a backend feels
pretty drastic... it would delete all of the backend's servers, and
their groups.

I should definitely be possible to DELETE a backend, but maybe this
should be excluded from the regular sync...?  There is a reason rsync has
--delete separate from --archive, it's so... destructive and final.

The Gnus client should PUT any new backends immediately.

When you get the server list for a backend, use conditional GET against
the .newsrc "last synchronized" timestamp, and if you get a 304 not
modified, then .newsrc.eld is the master in conflicts.

I see the same concerns about DELETE of servers, as for delete of
backends: ie. it should be possible, but maybe not part of the regular
sync.

The gnus client should PUT any new servers it has, as compared to the
gnus server, immediately.

I have no clear thoughts on GET of server parameters, and how they
should behave in case on conflicts.

When you get the group list for a server, use conditional GET against
the .newsrc "last synchronized" timestamp, and if you get a 304 not
modified, then .newsrc.eld is the master in conflicts.

Here I think it's OK to do a full sync, including DELETE of groups.
Worst case is that you lose the tick marks of a group, and that has
happened to me many times.

The gnus client should PUT and DELETE groups from detected differences
immediately. 

I have no clear thoughts on GET of group parameters, and how they should
be merged.

When doing a conditional GET of a group's marks, you will get a 304 not
modified if there are no marks newer than the timestamp.  If there are
marks newer than the timestamp, you will get a lisp or JSON list
containing their article numbers (possibly with the actual mark values
inlined). 

The gnus client should PUT all marks it has that has been set between
the "last synchronized" timestamp, and now, immediately.  This means
that the .newsrc.eld needs to hold some more timestamping.  Having a
timestamp on the individual tickmarks feels a bit heavy, but maybe it
should be tried...?  (I think the server needs to hold individual mark
timestamps, though)

When actually setting new tick marks, while online, the Gnus client
should just fire of PUTs for the tick marks as they are set.

When subscribing to new groups when online, the Gnus client should just
PUT them on the server.  Ditto for backends and servers (though they
would be rare).

That's all I have thought about, so far.