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