Re: gnus-sync ideas

[Steinar Bang <sb@dod.no>]

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

> The values will be data blobs with only one property: they can be
> merged.  Thus many data formats can be supported.

If you have more than one type of blob, don't you need some type
information?  Or do you plan to guess the type when using the data?  Or
do you mean to normalize to a single type?

SB> Hm... why so many formats?  We're not going for interoperability with
SB> anything else (ie. why use JSON?).  And what's the difference between
SB> elisp lists and the rtree format?  (FWIW I think the format should be
SB> s-expressions/elisp lists, because it is simple and low cost on the
SB> emacs side)

> rtree is much more compact that simple sexps for marks IIUC.
> So it makes sense to use it for marks, but it's not appropriate for
> many other formats.

Umm... what do you mean by "rtree" here?  The abstract rtree data
structure?  A particular non-lisp format?  Lars' lisp implementation of
rtrees in rtree.el?

The last one is something that can be fed the lisp reader, and are (as
far as I understand s-expressions) s-expressions as good as any...?

> That's easy to do as an optimization.  I'll try to get the basics
> working first.  The HTTP GET/POST semantics should be sufficient so
> PUT and DELETE won't be needed.

Why POST and not PUT?

Nothing important.  I'm just curious as to the reasoning?  It's like
XML attributes vs. elements: why pick one over the other? (well... not
quite.  If you are using a SAX style parser there are good reasons for
picking attributes over elements if you can, which is when there is no
hierarical values to represent, and no multiple values.  With POST and
PUT there aren't really good reasons for there to be two separate
mechanisms.  My rule of thumb is to use POST if you need to transfer
multiple values, eg. the value and some metainformation about the value,
and PUT if it is just the value).

Hm... when I think about it, there is at least one piece of
metainfomation that is neccessry: a timestamp.