OK, I've modified what I have in the clone so that the use of SocketIO is optional. To turn on SocketIO add "--use_socketio=true" to the server command line.
The changes that need to be reviewed are in the last two revisions of the clone: http://code.google.com/r/tadglines-socketio/ I don't know how to get those two revisions into a code review. You can do it if you want, but please tell me how as well. With this change, people can continue to use the original WebSockets or test out the new Socket.IO. -Tad On Tue, Oct 26, 2010 at 1:48 PM, Joseph Gentle <[email protected]> wrote: > Cool. Is the change ready for us to take a look at it? (I can throw up > a code review if it is). > > -J > > > On Tue, Oct 26, 2010 at 2:39 PM, Tad Glines <[email protected]> wrote: > > Because I anticipate multiple changes and because it deals with multiple > > files, I've created a clone and pushed the changes there. > > http://code.google.com/r/tadglines-socketio/ > > > > I've also included a fix for the reconnect issue I mentioned in my last > > e-mail on this thread. > > > > -Tad > > > > On Mon, Oct 25, 2010 at 5:06 PM, Tad Glines <[email protected]> > wrote: > >> > >> I was planning on documenting (in the socketio-java wiki) the > "protocols" > >> supported. The idea is to have a client/server interaction design that > its > >> independent of the implementations. > >> I can start by describing the message encoding. > >> > >> I also plan to write a HowTo describing how to use the server API and > GWT > >> client API, but both are in flux at the moment so I'm holding off until > I'm > >> a little happier with both. > >> > >> I submitted the patch early in the hope that people would try it and > >> report any problems they encounter. I've already identified one problem. > If > >> a connection attempt fails, nothing gets reported from Socket.IO so the > >> client doesn't know it needs to try again (state gets stuck in > CONNECTING). > >> I'm working on a fix for that (and altering the API slightly). > >> > >> -Tad > >> > >> On Mon, Oct 25, 2010 at 4:44 PM, Alex North <[email protected]> wrote: > >>> > >>> Hi Tad, > >>> Would you be willing to write up a quick design document describing, > for > >>> example, the different message encoding etc? > >>> > >>> On 24 October 2010 16:19, Tad Glines <[email protected]> wrote: > >>>> > >>>> All the transports are implemented and I've tested all but htmlfile in > >>>> Firefox and Chrome 6. I'm not sure which browser uses htmlfile but if > >>>> someone can tell me, I'll try and test that one as well. > >>>> > >>>> Testing at this point consisted of using the chat example and making > >>>> sure messages went both ways. > >>>> > >>>> This server will not work with existing versions of Socket.IO because > I > >>>> changed the message encoding format in order to support a few extra > message > >>>> types. > >>>> > >>>> > >>>> The socketio-java project is hosted at: > >>>> http://code.google.com/p/socketio-java/ > >>>> My fork of the Socket.IO project is at: > >>>> http://github.com/tadglines/Socket.IO > >>>> > >>>> My next step is to integrate this into WaiB and see if it still works. > >>>> The underlying message encoding is different from raw websocket > messages so > >>>> I plan to implement a java client that the consoleclient can use. > It'll use > >>>> the websocket transport and deal with the Socket.IO message encoding. > >>>> > >>>> The code is still demo quality (lack of comments, possible race > >>>> conditions/threading issues). I welcome any input at this time. > >>>> > >>>> -Tad > >>>> > >>>> > >>>> On Thu, Oct 21, 2010 at 2:57 PM, Joseph Gentle <[email protected]> > >>>> wrote: > >>>>> > >>>>> Awesome. > >>>>> > >>>>> Well, when you're happy enough with it, request a codereview and lets > >>>>> workshop it. > >>>>> > >>>>> -J > >>>>> > >>>>> On Thu, Oct 21, 2010 at 11:28 PM, Tad Glines <[email protected]> > >>>>> wrote: > >>>>> > I'm fairly certain I can have it working well enough and integrated > >>>>> > into > >>>>> > WiaB be the summit, but the code will probably still be demo-ware > >>>>> > quality. > >>>>> > > >>>>> > -Tad > >>>>> > > >>>>> > On Wed, Oct 20, 2010 at 10:01 PM, Joseph Gentle <[email protected] > > > >>>>> > wrote: > >>>>> >> > >>>>> >> Awesome work guys. Really looking forward to it all being > integrated > >>>>> >> in wave in a box. > >>>>> >> > >>>>> >> Do you think we'll have other browser support before the summit? > >>>>> >> > >>>>> >> -J > >>>>> >> > >>>>> >> > >>>>> >> On Fri, Oct 1, 2010 at 5:25 AM, Guillermo Rauch <[email protected] > > > >>>>> >> wrote: > >>>>> >> > I also developed http://socket.io. You can use the client and > >>>>> >> > implement > >>>>> >> > a > >>>>> >> > backend for it. It leverages websocket, websocket through Flash, > >>>>> >> > long > >>>>> >> > polling, iframes, multipart ajax, jsonp polling. > >>>>> >> > > >>>>> >> > On Thu, Sep 30, 2010 at 2:26 PM, Tad Glines < > [email protected]> > >>>>> >> > wrote: > >>>>> >> >> > >>>>> >> >> Thanks, that confirms it. If we want wave-in-a-box to work for > >>>>> >> >> users > >>>>> >> >> behind a proxy with browsers that don't support Web Sockets, > then > >>>>> >> >> an > >>>>> >> >> alternative to flash is needed. > >>>>> >> >> > >>>>> >> >> That leaves, to the best of my knowledge, two options. One, > roll > >>>>> >> >> our > >>>>> >> >> own > >>>>> >> >> long pooling implementation, or two, make use of the existing > >>>>> >> >> message > >>>>> >> >> routing capabilities of CometD (or some other Comet/Long > polling > >>>>> >> >> implementation). > >>>>> >> >> > >>>>> >> >> -Tad > >>>>> >> >> > >>>>> >> >> On Thu, Sep 30, 2010 at 7:43 AM, Guillermo Rauch > >>>>> >> >> <[email protected]> > >>>>> >> >> wrote: > >>>>> >> >>> > >>>>> >> >>> I wrote that part of the README and committed the relevant > >>>>> >> >>> patch. > >>>>> >> >>> More information > >>>>> >> >>> > >>>>> >> >>> here: > http://cometdaily.com/2008/09/30/why-flash-must-adopt-comet/ > >>>>> >> >>> > >>>>> >> >>> On Thu, Sep 30, 2010 at 11:31 AM, Tad Glines > >>>>> >> >>> <[email protected]> > >>>>> >> >>> wrote: > >>>>> >> >>>> > >>>>> >> >>>> The Flash based Web Socket implementation may not work behind > a > >>>>> >> >>>> proxy > >>>>> >> >>>> without some extra rigmarole. Here's the relevant text from > the > >>>>> >> >>>> web-socket-js README file: > >>>>> >> >>>> > >>>>> >> >>>> The AS3 Socket class doesn't implement this mechanism, which > >>>>> >> >>>> renders > >>>>> >> >>>> it > >>>>> >> >>>> useless for the scenarios where > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> the user trying to open a socket is behind a proxy. > >>>>> >> >>>> > >>>>> >> >>>> The class RFC2817Socket (by Christian Cantrell) effectively > >>>>> >> >>>> lets us > >>>>> >> >>>> implement this, as long as the > >>>>> >> >>>> proxy settings are known and provided by the interface that > >>>>> >> >>>> instantiates > >>>>> >> >>>> the WebSocket. As such, if you > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> want to support proxied conncetions, you'll have to supply > this > >>>>> >> >>>> information to the WebSocket > >>>>> >> >>>> constructor when Flash is being used. One way to go about it > >>>>> >> >>>> would be > >>>>> >> >>>> to > >>>>> >> >>>> ask the user for proxy > >>>>> >> >>>> settings information if the initial connection fails. > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> > >>>>> >> >>>> This was surprising. I had always assumed that Flash would > >>>>> >> >>>> obtain the > >>>>> >> >>>> proxy info from the host browser and use it when connecting > >>>>> >> >>>> back to > >>>>> >> >>>> the > >>>>> >> >>>> server. I haven't tested this yet so I can't be certain if > this > >>>>> >> >>>> is a > >>>>> >> >>>> real > >>>>> >> >>>> issue. If it is, then prompting the user for proxy > information > >>>>> >> >>>> is > >>>>> >> >>>> not, in my > >>>>> >> >>>> opinion, a valid solution. > >>>>> >> >>>> > >>>>> >> >>>> We also know that Web Sockets (native or flash) don't work on > >>>>> >> >>>> iOS > >>>>> >> >>>> based > >>>>> >> >>>> devices. > >>>>> >> >>>> > >>>>> >> >>>> I recently did some work using CometD and I noticed that, > >>>>> >> >>>> besides > >>>>> >> >>>> long > >>>>> >> >>>> pooling, it also supports Web Sockets as one of its > transports. > >>>>> >> >>>> And, > >>>>> >> >>>> it also > >>>>> >> >>>> seems to have automatic fallback support. Perhaps using > CometD > >>>>> >> >>>> would > >>>>> >> >>>> be a > >>>>> >> >>>> better alternative to the Flash based Web Sockets. There is > >>>>> >> >>>> also a > >>>>> >> >>>> CometD > >>>>> >> >>>> java client library so the console client could also > interface > >>>>> >> >>>> with > >>>>> >> >>>> the > >>>>> >> >>>> server via CometD over Web sockets. > >>>>> >> >>>> > >>>>> >> >>>> The one downside I see is that the Bayuex protocol adds some > >>>>> >> >>>> additional > >>>>> >> >>>> overhead (channel ID, message ID, timestamp, etc...). We > could > >>>>> >> >>>> implement our > >>>>> >> >>>> own long polling based alternative to Web Sockets, but why > >>>>> >> >>>> re-invent > >>>>> >> >>>> the > >>>>> >> >>>> wheel. > >>>>> >> >>>> > >>>>> >> >>>> Also, it's possible to combine the Flash based Web Sockets > impl > >>>>> >> >>>> with > >>>>> >> >>>> CometD since CometD will fall back to long polling if it > fails > >>>>> >> >>>> to > >>>>> >> >>>> establish > >>>>> >> >>>> a connection using Web Sockets. > >>>>> >> >>>> > >>>>> >> >>>> -Tad > >>>>> >> >>>> > >>>>> >> >>>> -- > >>>>> >> >>>> You received this message because you are subscribed to the > >>>>> >> >>>> Google > >>>>> >> >>>> Groups "Wave Protocol" group. > >>>>> >> >>>> To post to this group, send email to > >>>>> >> >>>> [email protected]. > >>>>> >> >>>> To unsubscribe from this group, send email to > >>>>> >> >>>> [email protected]<wave-protocol%[email protected]> > . > >>>>> >> >>>> For more options, visit this group at > >>>>> >> >>>> http://groups.google.com/group/wave-protocol?hl=en. > >>>>> >> >>> > >>>>> >> >>> > >>>>> >> >>> > >>>>> >> >>> -- > >>>>> >> >>> Guillermo Rauch > >>>>> >> >>> http://devthought.com > >>>>> >> >>> > >>>>> >> >>> -- > >>>>> >> >>> You received this message because you are subscribed to the > >>>>> >> >>> Google > >>>>> >> >>> Groups > >>>>> >> >>> "Wave Protocol" group. > >>>>> >> >>> To post to this group, send email to > >>>>> >> >>> [email protected]. > >>>>> >> >>> To unsubscribe from this group, send email to > >>>>> >> >>> [email protected]<wave-protocol%[email protected]> > . > >>>>> >> >>> For more options, visit this group at > >>>>> >> >>> http://groups.google.com/group/wave-protocol?hl=en. > >>>>> >> >> > >>>>> >> >> -- > >>>>> >> >> You received this message because you are subscribed to the > >>>>> >> >> Google > >>>>> >> >> Groups > >>>>> >> >> "Wave Protocol" group. > >>>>> >> >> To post to this group, send email to > >>>>> >> >> [email protected]. > >>>>> >> >> To unsubscribe from this group, send email to > >>>>> >> >> [email protected]<wave-protocol%[email protected]> > . > >>>>> >> >> For more options, visit this group at > >>>>> >> >> http://groups.google.com/group/wave-protocol?hl=en. > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > -- > >>>>> >> > Guillermo Rauch > >>>>> >> > http://devthought.com > >>>>> >> > > >>>>> >> > -- > >>>>> >> > You received this message because you are subscribed to the > Google > >>>>> >> > Groups > >>>>> >> > "Wave Protocol" group. > >>>>> >> > To post to this group, send email to > >>>>> >> > [email protected]. > >>>>> >> > To unsubscribe from this group, send email to > >>>>> >> > [email protected]<wave-protocol%[email protected]> > . > >>>>> >> > For more options, visit this group at > >>>>> >> > http://groups.google.com/group/wave-protocol?hl=en. > >>>>> >> > > >>>>> >> > >>>>> >> -- > >>>>> >> You received this message because you are subscribed to the Google > >>>>> >> Groups > >>>>> >> "Wave Protocol" group. > >>>>> >> To post to this group, send email to > [email protected]. > >>>>> >> To unsubscribe from this group, send email to > >>>>> >> [email protected]<wave-protocol%[email protected]> > . > >>>>> >> For more options, visit this group at > >>>>> >> http://groups.google.com/group/wave-protocol?hl=en. > >>>>> >> > >>>>> > > >>>>> > -- > >>>>> > You received this message because you are subscribed to the Google > >>>>> > Groups > >>>>> > "Wave Protocol" group. > >>>>> > To post to this group, send email to > [email protected]. > >>>>> > To unsubscribe from this group, send email to > >>>>> > [email protected]<wave-protocol%[email protected]> > . > >>>>> > For more options, visit this group at > >>>>> > http://groups.google.com/group/wave-protocol?hl=en. > >>>>> > > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "Wave Protocol" group. > >>>>> To post to this group, send email to [email protected]. > >>>>> To unsubscribe from this group, send email to > >>>>> [email protected]<wave-protocol%[email protected]> > . > >>>>> For more options, visit this group at > >>>>> http://groups.google.com/group/wave-protocol?hl=en. > >>>>> > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Wave Protocol" group. > >>>> To post to this group, send email to [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]<wave-protocol%[email protected]> > . > >>>> For more options, visit this group at > >>>> http://groups.google.com/group/wave-protocol?hl=en. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "Wave Protocol" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]<wave-protocol%[email protected]> > . > >>> For more options, visit this group at > >>> http://groups.google.com/group/wave-protocol?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/wave-protocol?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
