Re: gnus sync

[Steinar Bang <sb@dod.no>]

>>>>> 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.

The RESTful approach I suggested earlier isn't very appropriate for
that, however.  It has nice URLs, but would be clumsy to use.

Eg. structuring servers under their backends looks nice, but has no
practical use for gnus.  And structuring groups under the servers also
looks nice, but has no practical use.

Also structuring different information under a server (properties and
newsgroups), and under newsgroups (properties and tickmarks), makes it
hard to request information across servers and groups (eg. what servers
or groups have properties more recent than a given timestamp).

Basically, what gnus wants from a server, would be:
 - The list of servers (with some way of identifying servers that have
   been added or deleted, compared to what the gnus instance has)
 - A simple way to get the server properties for the servers that has
   more recent server properties than the one the gnus instance has
 - The list of active newsgroups (with some way of identifying groups
   that have been added or removed compared to what the gnus instance
   has)
 - A simple way to get the group properties for groups that has more
   recent properties than what the gnus client has
 - A simple way to get the tick marks for a group, that is more recent
   than a given time stamp

So here's a new suggestion:

At the top there are three URLs:
 https://myserver/gnussync/servers
 https://myserver/gnussync/groups
 https://myserver/gnussync/groupprops

Doing a GET on
 https://myserver/gnussync/servers
will return at JSON or lisp list of all servers the sync server knows
about.

The list will contain server names on the form "backend+servername".
(Question: should the list also contain creation and last-modified time
stamps?)

Doing a PUT of a new server, eg
 https://myserver/gnussync/servers/backend+servername
then the body of the PUT request is expected to be server properties in
.newsrc.eld form (will be treated as a blob on the sync server).

Doing a PUT of an already existing server, should fail.  Do a DELETE of
the existing server first (should probably also delete all groups
associated with that server...?).

Doing a GET of the server, will result in the server properties in
.newsrc.eld form.

Doing a GET on either
 https://myserver/gnussync/groups
or
 https://myserver/gnussync/groupprops
will result in the same JSON or lisp list of group names, that follow
the gnus group name form of "backend+servername:group.name".

The "groupprops" results may also contain time stamps ("creation" and
"last modified"), if that's more convenient.

GET of a groupprops group URL, eg
 https://myserver/gnussync/groupprops/backend+servername:group.name
will return the group properties in .newsrc.eld form.

PUT on a grouppropes group URL will take the body of the PUT request and
set that as the new group properties for that group on the sync server.
PUT on an existing groupprops URL will overwrite the data.

GET on a groups group URL
 https://myserver/gnussync/groups/backend+servername:group.name
will return a JSON or lisp list containing all the article numbers of
the articles of the group, that have tick marks set.

To get the actual tick mark, GET the article, eg.
 https://myserver/gnussync/groups/backend+servername:group.name/articlenumber

Doing a GET with a cutoff argument, eg
 https://myserver/gnussync/groups/backend+servername:group.name?cutoff=2011-07-10-09:02:55
will return only the tick marks that have been set after the cutoff
date.

(It should probably be possible to get the tick marks inlined into the
group GET results...?)

Doing a PUT of an article number in a group, will take the body of the
PUT request to be the new tickmark.  PUTing over an existing tick mark
will overwrite that tick mark.

DELETE on an article number will remove the tick mark information for
that article.