On Fri, Feb 6, 2015 at 8:54 AM, Fraser Adams <fraser.ad...@blueyonder.co.uk> wrote:
> > >> It sounds like we quite probably would want to keep any web socket stuff >> compile-time optional and simply not build it at all with emscripten. That >> would a) avoid the possibility of nested websocketry, and b) keep useless >> code out of the already large proton.js file. >> > > It's worth keeping an open mind. The proton-messenger.js stuff it indeed a > bit big, most of that is actually down to the emscripten runtime stuff and > there's a limit to what is easy to strip, there's some work ongoing on > emscripten to make this a bit better. It's <500K minified and it could be > compressed. I'm all for making it smaller but I doubt it'll make a huge > difference I'm afraid. My main concern would be to make sure that any bits > of code to add an API to select between TCP and WebSockets *weren't* > removed I *want* to be able to pass that info to the emscripten code for > when I get round to adding native TCP support. > Ah, that's good to know. For some reason I was assuming the overhead was from our own code, but if it's not then hopefully as you say it will just improve with time and we don't need to do much about it. > > >> I think this should be fairly straightforward in proton-c. We already >> have a similar set of scenarios there with SSL and SASL autodetect. When >> you configure a Transport, you basically construct a stack of protocols. In >> server mode you can it autodetect whether each layer is present and fall >> through to the next. In client mode the stack is just what you have >> specified. >> > > So I can see how the autodetect could be extended to handle this when > acting as a server, but this last bit was really about what sort of "API" > one might use for a client to establish a connection giving a runtime > choice between a TCP or WebSocket transport. As I say for the > qpid::messaging API the Connection allows quite a range of options but in > Messenger at any rate I think the options are more limited and ISTR there > are some restrictions even on SASL options, so as I say it's probably not > "technically" hard I'm just not sure what the best "specify the transport" > API might be for Proton - if you see what I mean? > > Yeah, I see what you mean. I suspect there will probably be multiple layers here. When constructing the transport directly the API choices are fairly straightforward, but probably overly verbose and flexible for what you would necessarily want as the common end-user case. I can imagine some sort of more convenience/configuration oriented layer on top that would let you just specify all the relevant details in a connect string or something like that. I believe Gordon already has something like this in the reactive API, so that might give you an answer. --Rafael
