Addition of HTTP semantics based cometd transport: HTTP Channels

[kriszyp]

This ticket is for the addition of a HTTP based cometd transport that utilizes the semantics of HTTP for metadata, message encapsulation, and REST information. This is mainly to provide visibility for this project that I am working on, and see if there is any feedback on it. This transport will implement the required methods for a cometd transport, and automatically plugs in as a cometd transport called "http-channels". The transport will be capable of running standalone and providing additional functionality beyond that of cometd like requesting a resource and subscribing to it at the same time. This transport can also optionally function as an enhancement to the RPC service's REST transport, to provide a means for "live" data access. Authors will be able to use the REST service, and then receive notifications of resource modifications as data changes. This will allow JsonRestStore? to provide a live view of RESTful data, resource changes will be propagated as dojo.data notification events. This addition will also involve some corrections to dojox.cometd._base to improve support for additional transports.

[Jared Jurkiewicz]

Who is implementing this? Who should it be assigned to?

[kriszyp]

I am implementing it, I just filed the ticket so it would have a ticket and I could see if there are any concerns/issues related to it. This is cometd (so maybe Alex), but it will have an effect on RPC (maybe Dustin) and some of the dojox.data stores, so I am not sure who it should be assigned to.

[kriszyp]

Or obviously it could be assigned to me, just wasn't sure if you wanted it assigned to a committer.

[Jared Jurkiewicz]

I'll just assign it over to you, since you're doing it.

[kriszyp]

HTTP Channels

[dylan]

Kris, I've noticed some code blocks commented out in a few places. Should those be removed?

Alex, can we get a code review on this patch please?

[Kris Zyp]

(In [14136]) fixes #6131