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