Comments for page "RestMS Goes Atomic"

(no title)

Wed, 11 Feb 2009 09:15:55 +0000

The WebSocket protocol looks interesting but right now it looks like we'll use RestMS/HTTP for simple-slow scenarios and AMQP for binary-fast scenarios. As soon as we diverge from HTTP and the advantages that gives us (standard clients, network support, etc.) then we pay a price for using exotic protocols, and we might as well use the one that works best, which is AMQP for this work.

I'm going to look at using extprot for multipart documents, and also for structured content that can be transcoded on the fly into XML or JSON for clients. This definitely looks useful.

(no title)

Wed, 11 Feb 2009 08:08:45 +0000

Appreciate not wanting to use 'extension' headers. I still wonder if the WebSocket spec/discussion isn't relevant? Worth tracking/implementing?

http://www.whatwg.org/specs/web-apps/current-work/#network

In another comment I gave a heads-up on extprot not sure if that helps indirectly - my intention had been to use it as the multipart body, if the server had several msg ready it could dump them in one part of multi-part document - the client could decode several messages since extprot allows self delimiting.

Re: RestMS vs WebSocket vs REST channels....

Mon, 09 Feb 2009 08:47:27 +0000

From a quick read up on Dojo Rest channels, part of this is already implemented with the concept of pipes, and part with asynclets, which work pretty much as Comet, except right now we don't have specifications for multi-part messages. That is meant to be solved with a "streaming" pipe type.

We've not used any HTTP headers except the standard ones, and I like that. So the next stages are to ensure the basic semantics of RestMS make sense, and then to look at optimizing the two main cases where performance is an issue, publishers that send streams of data, and subscribers that receive streams of data. In both cases we'd do that by keeping open a connection and then sending messages with no confirmations. Some efficient multipart format that lets us include a binary-encoded envelope (XML and JSON are simple but too expensive for really high volume cases).

We already use simple binary envelope encoding in OpenAMQ (http://wiki.amqp.org/spec:6) and I'd like to see how that can be mapped to an HTTP multipart format. Any ideas?

RestMS vs WebSocket vs REST channels....

Mon, 09 Feb 2009 01:34:32 +0000

FYI, some thoughts, issues and resources:
http://restlet.tigris.org/issues/show_bug.cgi?id=143

Also how does RestMs compare to REST channels implemented in Dojo? Couldn't they share 'specs' e.g. the header extensions such as:
X-Create-Client-Id: 3254325325
X-Client-Id: 3254325325
X-Subscribe: *
etc?
How 'in sync' is RestMS with the proposals on WebSocket?
How different to Comet/REST Channels, e.g.:
http://cometdaily.com/2008/09/02/rest-channels-http-channels-with-json-support/
http://cometdaily.com/2008/11/12/using-rest-channels-in-dojo/
http://api.dojotoolkit.org/jsdoc/dojox/HEAD/dojox.cometd.RestChannels

An elegant description:
http://www.subbu.org/blog/2006/04/dissecting-ajax-server-push

HTH