On 06/02/15 14:28, Alan Conway wrote:
On Fri, 2015-02-06 at 08:19 -0500, Rafael Schloming wrote:
A couple of questions/comments inline, but first off, any reason this
isn't on the list? (I don't mind, just curious.)
No good reason, including list now.
Extremely useful discussion, thanks! Taking it all on board.
New question: For dispatch I only care about the server side. JavaScript
is the only websocket client I know of and as per discussion below we
would actually need to *exclude* proton client-side websocket support
from the JS client, so maybe we don't need it at all. Are there use
cases for a websocket client transport?
Snipped the rest to save it getting out of hand for this response :-)
RE "Are there use cases for a websocket client transport? " yeah, the
JavaScript client uses WebSockets ;-p but also Rob has a Java WebSocket
client (qpid/java/amqp-1-0-client-websocket...).
To be fair I'd agree that allowing TCP *and* WebSocket inbound
connections is the most obvious/compelling use case, so I'd be happy if
the priority was there, but I'd be concerned of too narrow a focus - as
I mentioned on some of my responses to Rafael there are a few cheeky API
gotchas when considering allowing optional transports and for that
reason they are worth considering.
I'm definitely considering the case for Node.js where an application
might want to be able to establish either a TCP or a WebSocket based
outbound connection, indeed at the moment only the latter is supported
and I'd suggest that as Dispatch is a router it really needs to be
capable of a wide range of transports.
As I said on my earlier ramble it *might* turn out to not be so awkward,
for the server side the ws/emscripten stuff removes all the WebSockety
bits and pushes up basically the raw AMQP octet stream, so I think the
autodetect stuff in transport would then be oblivious of the fact that
the JavaScript stuff had been over WS it would think it was just
receiving off a TCP socket. Establishing a connection OTOH is, as I
say,a bit dependent on some sort of API for saying TCP or WebSocket and
I think that'd be useful - question does Proton support RDMA? I know
qpidd/qpid::messaging does, so there's a use case beyond just WebSockets
for that sort of API (and RCTP might be another worthwhile transport for
AMQP).
FWIW I'm seriously considering expending some energy getting AMQP over
WebRTC working, I reckon that'd be pretty cool going forward. So at some
point I might like Dispatch to be able to establish a WebRTC connection
to a browser - but lets tackle WebSockets before I get too carried away
:-D #haveiscaredyouyet
Frase
