Gnus development mailing list
 help / color / mirror / Atom feed
From: Steinar Bang <sb@dod.no>
To: ding@gnus.org
Subject: Re: gnus sync
Date: Sun, 10 Jul 2011 21:31:05 +0200	[thread overview]
Message-ID: <87zkkmkk5i.fsf@dod.no> (raw)
In-Reply-To: <871uyajgxw.fsf@lifelogs.com>

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

[snip!]
> My plan is the same as before: server-centric, accepts a few formats,
> does merge/intersection/reset, and outputs into JSON and Lisp
> expressions.

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

You would have a URL space where you PUT and GET URLs, and where the
local path part changes, according to the resource you are PUTing and
GETing.

By GET, PUT, and DELETE, I mean the HTTP commands.

User authentication and user selection would be done, using HTTP
authentication, such as basic, or digest-md5 (not excluding unofficial
ones like NTLM or kerb, if emacs and the server both can get support for
it.

Format selection, and date information, will be provided using HTTP
headers.

At the top you would have something like
 https://myserver/gnussync/backends

Doing GET on this URL would list all synced backends as a lisp or JSON
list.  Which format you desire you can set with the Accept-Format
header.

You can create a new backend with a PUT to a child of "backends", eg.
 https://myserver/gnussync/backends/nnmybackend
Trying to re-PUT an existing backend should fail.  You would explicitly
have to DELETE it first.

If you GET a backend, eg.
 https://myserver/gnussync/backends/nntp
you would get the list of servers for that backend, as a JSON or lisp
list.

Like for backends, creating a new server will be done with PUT, and
trying to PUT an existing server should fail.  An existing server would
have to be DELETE'd before it could be re-PUT.

If you GET a server, eg. 
 https://myserver/gnussync/backends/nntp/news.gmane.org
you will get a list with two members "parameters" and "groups"

I haven't given much thought to the behaviour of
 https://myserver/gnussync/backends/nntp/news.gmane.org/parameters

If you GET the "groups" of a server, eg.
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups
you will receive the groups of that server as a lisp or JSON list.

A new group can be created by doing a PUT of a sub-URL of the "groups",
eg. 
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.new.group

Trying to PUT an existing group should fail.  An existing group would
have to be DELETE's befor a new one could be PUT in its place.

If you GET a group, you will get a lisp, or JSON list containing two
members: "parameters" and "marks".

I haven't given much thought to the behaviours of group parameters, like
eg. 
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.emacs.gnus.general/parameters

If you GET a group's "marks", eg.
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.emacs.gnus.general/marks
you will receive a lisp or JSON list of all of the articles of that
group where tickmarks have been set.

Doing a "marks" GET with no qualifiers should return all of the marks
set.  I haven't figured out if the appropriate way of getting marks
newer than a cut-off, is by doing a conditional GET, or by adding an
argument, like eg.
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.emacs.gnus.general/marks?cutoff=2011-07-10-09:02:55

New marks are created, or old ones are updated, by doing a PUT of the
article number, eg.
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.emacs.gnus.general/marks/79313

Doing a PUT of an existing mark isn't an error.  The newest will win.

A tick mark be retreived by using a direct GET of a tickmark URL.

Even though it may be in breakage of REST rules (is it...?) it may be
convenient to get the tick marks together with the lisp or JSON list of
tick marks, eg. by using an argument:
 https://myserver/gnussync/backends/nntp/news.gmane.org/groups/gmane.emacs.gnus.general/marks?cutoff=2011-07-10-09:02:55&inlinemarks=true

That's how far my thoughts have gone.




  reply	other threads:[~2011-07-10 19:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 12:07 Richard Riley
2011-06-30 14:38 ` Ted Zlatanov
2011-07-01  7:22   ` Steinar Bang
2011-07-01 12:58     ` Ted Zlatanov
2011-07-10 19:31       ` Steinar Bang [this message]
2011-07-14  6:24         ` Steinar Bang
2011-07-14  7:47           ` Steinar Bang
2011-07-14  7:39         ` Steinar Bang
2011-07-30 21:03           ` Steinar Bang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkkmkk5i.fsf@dod.no \
    --to=sb@dod.no \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).