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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
