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