Hey guys, thanks for the responses. You're right, the motive why I can't use the WebSockets interface is that although the header information for the WebSockets protocol is based on HTTP headers, it's not HTTP and you cannot open a WebSocket connection to an HTTP endpoint.
The only other option for network connectivity within browser based clients is using the XmlHttpRequest interface for opening HTTP connections, that's perfectly fine for the REST and the search APIs, however, trying to establish a persistent connection with the XmlHttpRequest interface for use with the streaming API doesn't seem possible. As for cross-origin requests policy I think WebSockets rely on the Cross-Origin Resource Sharing specification [1] authorizing or not the connection based on a whitelist sent by the server on the response header. So that's probably a non-issue. Another benefit that I can imagine is that WebSockets allow a 2-way persistent connection. Because it's a 2-way connection that could make it a lot easier to update the filter predicate without the necessity of reconnecting, but that's another story. :) [1] http://www.w3.org/TR/access-control/ Again, thanks for your hard work, Cezar Sá Espinola @cezarsa On Sun, May 16, 2010 at 3:29 PM, John Kalucki <j...@twitter.com> wrote: > I did a quick reading, and I couldn't tell if WS connections are > restricted back to the domain of the calling page, or if arbitrary > connections are allowed. If the former, there may not be a reason for > the Streaming API to support this. If the latter, perhaps there's a > valid use case. > > Looking at the protocol itself, this wouldn't be trivial to support, > but it might not be that bad either. We'll have to keep an eye on the > installed browser base and see when this might make sense. > > It is too bad that they didn't allow HTTP connections with incremental > byte reads in addition to WB connections on that interface. I'm sure > they had their reasons. > > -John Kalucki > http://twitter.com/jkalucki > Infrastructure, Twitter Inc. > > > > On Sat, May 15, 2010 at 3:22 PM, Abraham Williams <4bra...@gmail.com> > wrote: > > I'm not particularly familiar with the specifics of WebSockets but here > is > > the draft documentation: http://dev.w3.org/html5/websockets/ > > I don't see Chrome Extensions as being any different from desktop > > applications as they are both manually installed by the user on their > > desktop. > > Abraham > > > > On Sat, May 15, 2010 at 09:02, John Kalucki <j...@twitter.com> wrote: > >> > >> The first release of User Streams is not intended for web clients due > >> to capacity constraints. > >> > >> http://apiwiki.twitter.com/ChirpUserStreams > >> " > >> All services, mobile and browser-based clients must not use Streaming > >> until we've sorted out Desktop clients at some scale. One problem at a > >> time. > >> " > >> > >> That being said, of course we'd like to encourage experimentation with > >> other client types, so that clients can evolve as we scale out the > >> service. > >> > >> While others at Twitter are well-versed in the latest browser > >> technologies, I'm totally and willfully ignorant. If you could give a > >> brief summary of how the existing Streaming API does not work for > >> WebSockets, that might be helpful. What's missing? > >> > >> -John Kalucki > >> http://twitter.com/jkalucki > >> Infrastructure, Twitter Inc. > >> > >> > >> > >> On Fri, May 14, 2010 at 9:38 PM, Cezar Sá Espinola <ceza...@gmail.com> > >> wrote: > >> > Hey guys, > >> > Quick question, are there any plans on supporting WebSockets protocol > >> > for > >> > the Streaming API? > >> > That'd be awesome for browser based Twitter clients (i.e. Google > Chrome > >> > extensions). Without this it'll be very difficult for this kind of > >> > client to > >> > lavarage benefit from the upcoming user streams. > >> > Thanks a lot for all your hard work, > >> > Cezar Sá Espinola > >> > @cezarsa > > > > > > > > -- > > Abraham Williams | Developer for hire | http://abrah.am > > @abraham | http://projects.abrah.am | http://blog.abrah.am > > This email is: [ ] shareable [x] ask first [ ] private. > > >
