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