From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/75475 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus-sync ideas Date: Wed, 29 Dec 2010 23:07:13 +0100 Organization: Probably a good idea Message-ID: <87ipycb5da.fsf@dod.no> References: <87zks9ecf7.fsf@dod.no> <87r5djxahm.fsf_-_@lifelogs.com> <87fwttv83u.fsf@dod.no> <87bp472qbd.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1293660523 1701 80.91.229.12 (29 Dec 2010 22:08:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Dec 2010 22:08:43 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M23826@lists.math.uh.edu Wed Dec 29 23:08:35 2010 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 1PY4CB-000452-5F for ding-account@gmane.org; Wed, 29 Dec 2010 23:08:35 +0100 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 1PY4BC-0008Gy-RS; Wed, 29 Dec 2010 16:07:34 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PY4B9-0008Gi-Nn for ding@lists.math.uh.edu; Wed, 29 Dec 2010 16:07:31 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PY4B5-0005JU-Eq for ding@lists.math.uh.edu; Wed, 29 Dec 2010 16:07:28 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1PY4B3-0006bG-B1 for ding@gnus.org; Wed, 29 Dec 2010 23:07:25 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PY4B3-0003hk-6F for ding@gnus.org; Wed, 29 Dec 2010 23:07:25 +0100 Original-Received: from ti0064a380-0346.bb.online.no ([85.166.28.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Dec 2010 23:07:25 +0100 Original-Received: from sb by ti0064a380-0346.bb.online.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Dec 2010 23:07:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 47 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ti0064a380-0346.bb.online.no Mail-Copies-To: never User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) Cancel-Lock: sha1:SlbYFGdMTijy8yz91ju50EdIH8Y= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:75475 Archived-At: >>>>> Ted Zlatanov : > 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.