Bi-directional

[rektide]

Greetings Jeanfrancois Arcand & all others,

As a potential implementor of the SwaggerSocket Protocol, I'm curious what the plan is going
forwards for bi-directional communication, particularly at the Protocol level.

When I implemented a similar HTTP messaging transport, Pipe-Layer, I required a channel already
be opened via the client, and then allowed the server to wire Request objects to the client,
so long as there was an existing valid channel. Is this at all inline with SwaggerSocket's
thinking for the reverse case, or is the notion of a web-serving client overly distasteful/
something more detached from bidirectional tossing around of message-oriented Request & Response
objects?

One question about https://github.com/wordnik/swaggersocket/wiki/SwaggerSocket-Protocol :
how does the request get mapped to the UUID? I presume, as with Pipe-Layer, there is a
per-channel key which will match across the issued Request and the returning response?
("uuid" in swaggersocket v. "x-seq"/"x-rseq" in pipe-layer)? This is a secondary identifier,
distinct from the "identity" identifier which ID's the channel ("identity" in swaggersocket"
v. "x-pipe" in pipe-layer)?

Last, you'd be my #1 if you'd prop up a demo instance that does some trivial activity. I
realize running the demo app isn't hard, but it'd be great to have something easy to tell
people to hit with their developer console of choice, would make a great advocacy tool.

Gratzi!
rektide

[tony tam]

Hi Rektide,

Bi-directional is absolutely part of the swaggersocket plan.  The current implementation shows the usual REST operations but as you mentioned, websocket gives the server message push capability.  We will have a swaggersocket feature similar to "Suspend" in Atmosphere which allows a connected client to receive push messages.

Regarding the UUID, there are two parts.  1) The server keeps track of a connected client with a server-side ID.  2) the client library generates the UUID so that async messages can be appropriately routed.

We will be adding more examples to show how the message routing works on the client and of course when we expose the syntax for the full-duplex/push messages to the client.

Tony

[Jeanfrancois Arcand]

Salut,

On 12-05-01 8:54 AM, tony tam wrote:

Hi Rektide,

Bi-directional is absolutely part of the swaggersocket plan.  The current implementation shows the usual REST operations but as you mentioned, websocket gives the server message push capability.  We will have a swaggersocket feature similar to "Suspend" in Atmosphere which allows a connected client to receive push messages.

The simplest way is to inject an AtmosphereResource

   @Context AtmosphereResource

and then use that object to write object back to client. AtmosphereResource has #write method that exactly do what you want.

A+

-- Jeanfrancois