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]. >>>>> >> >>>> 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]. >>>>> >> >>> 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. >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > -- >>>>> >> > 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]. >>>>> >> > 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. >>>>> >> >>>>> > >>>>> > -- >>>>> > 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. >>>>> > >>>>> >>>>> -- >>>>> 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. >>>>> >>>> >>>> -- >>>> 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. >>> >>> -- >>> 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. >> > > -- > 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. > -- 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.
