From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79600 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus sync Date: Sat, 30 Jul 2011 23:03:10 +0200 Organization: Probably a good idea Message-ID: <87vcujbhwx.fsf@dod.no> References: <9uhb77o73s.fsf@news.eternal-september.org> <87wrg3v0yi.fsf@lifelogs.com> <87boxebh2q.fsf@dod.no> <871uyajgxw.fsf@lifelogs.com> <87zkkmkk5i.fsf@dod.no> <87bowxgvjk.fsf@dod.no> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312059826 8113 80.91.229.12 (30 Jul 2011 21:03:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 30 Jul 2011 21:03:46 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M27896@lists.math.uh.edu Sat Jul 30 23:03:43 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QnGhA-0004ZZ-4H for ding-account@gmane.org; Sat, 30 Jul 2011 23:03:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1QnGgz-0001JS-2H; Sat, 30 Jul 2011 16:03:29 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1QnGgw-0001J8-Vb for ding@lists.math.uh.edu; Sat, 30 Jul 2011 16:03:26 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QnGgv-00067c-1N for ding@lists.math.uh.edu; Sat, 30 Jul 2011 16:03:26 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1QnGgt-0000BM-Kb for ding@gnus.org; Sat, 30 Jul 2011 23:03:23 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QnGgs-0004Qy-Uc for ding@gnus.org; Sat, 30 Jul 2011 23:03:22 +0200 Original-Received: from cm-84.208.226.30.getinternet.no ([84.208.226.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Jul 2011 23:03:22 +0200 Original-Received: from sb by cm-84.208.226.30.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Jul 2011 23:03:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 105 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.226.30.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:vUuUDKYY9pNdYBqdZWzBTDTHL3w= X-Spam-Score: -6.1 (------) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79600 Archived-At: >>>>> Steinar Bang : >>>>> Steinar Bang : >> 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.