Greg Wilkins communication proposal

From MemberWiki

Jump to: navigation, search


Greg Wilkins Communication Proposal

This page present a proposal approach to meet the concerns outlined in Interoperability_Communication

Implementation vs Interface

I do not believe that it is possible at this time for the OAA to specify a protocol implementation or even a wire protocol for Ajax communications. Any such attempt would quickly bog down in discussions such as:

  • XML vs JSON encapsulation
  • Single transport or multi transport (eg iframes, XHR, etc.)
  • cross site support

Additional down sides of a specific implementation include:

  • Require server side support, which would be a hindrance to it's general up take and be a further source of debate and delay.
  • Would stifle innovation and future browser support.

Instead, I propose that the OAA hub provide only the client side API of an Ajax transport and default implementation that simply wraps XHR with it's current capability. Alternate implementations may be plugged into the hub to provide advance transport features to all frameworks and clients using the hub and the API could also eventually be mapped to future browser support for transport.

Ajax Transport API

publish/subscribe API

An interface that encapsulates messaging via a publish subscribe paradigm similar to JSM topics or the cometd channels. The intent would be to allow various implementations to be plugged into the API (eg activemq Ajax support, DOJO cometd).

The API should have the following features:

  • channels identified by URLs
  • may transport plain text, JSON, XML
  • default implementation is simple XHR dispatch to channel URL

request/response API

The majority of Ajax applications are based on the request/response paradigm and will continue to be so. However, by providing a request/response API, the hub would allow many of the deficiencies of XHR to be avoided while not imposing a significant porting burden.

The Default implementation provided by the hub would simply map the XHR and require no server side changes or support. Pluggable implementations of the API would allow the request/response to be transported either over the messaging layer or over shared connections with messaging. Alternative server side implementations may map the request calls back to HTTP request/responses or keep them as messages.

capability assertion / configuration

An Ajax application should be able to assert the capabilities they require: request/response, out bound messaging, in-bound messaging, minimum latency etc.

The hub would verify that the capability requirements of all components and frameworks of the page can be met by the provided transport implementation - or throw and exception. Some degree of configuration would also result (eg starting polling if needed).

This should be dynamic, so that if all components no longer require server to client messaging, the connections can be dropped.

transport events

A set of standard events would be defined within the transport and published to the hubs event mechanism. These events would include:

  • Start of server to client messaging (ie client is active and user should be informed)
  • End of server to client message (client is no longer connected to server).
  • Multiple windows/tabs detected for same host
Personal tools