I'm going to keep the whole thread here because I think some important distinctions are being raised / discussed.
1. As a developer, I have to create a (minimum) viable product. "Viable" implies there must be a user interface beyond the command line. Yes, I know Cameron Kaiser thinks otherwise, but the people that I'm hoping will pay me money for a Twitter desktop product will most likely not want a command line product. 2. The most efficient way for me to deliver that UI, given oAuth, is to fire up a native browser and use it for at least the oAuth authentication and "view" portion of my application. I'm also guessing that one of the "industry standard" JavaScript libraries will be involved. Lots of wheels to not re- invent, etc.. 3. Twitter shouldn't have to care about the "model" and "controller" portions of my application. I'm guessing they'll not be in browser-side JavaScript, though, unless the JavaScript engines are a lot more efficient than I think they are. ;-) 4. That leaves the interface to user streams. Twitter should only have to care about connection-related and bandwidth-related parameters, *not* about whether I connect with Perl, Ruby, PHP, Python, JavaScript, C, Java, or even Lisp, Scheme or Forth. And Twitter shouldn't have to care whether the code is executed inside a browser by an interpreter, by compiled Java applet code, outside the browser by interpreted or compiled code, etc. Remember, I've got to have the browser anyway! In my case I'm guessing the connection will be Perl and outside the browser, because I know how to do things efficiently in Perl better than the others. And I'm guessing my model will require Perl efficiency as well. But if someone can build the whole enchilada in a browser, it shouldn't matter to Twitter as long as the connection and bandwidth properties are predictable / controllable. And, in fact, if *they're* ready to go to market the day user streams graduates to production status and I'm still futzing with my Perl code, well, I lose. ;-) 5. So let me throw a *huge* "what if?" on the table. What if there was an official Twitter-supported @anywhere - user streams capability? Then we *could* write a large chunk of a Twitter client in browser-side JavaScript. Maybe even simple models could be done that way too, but certainly the view and controller pieces could. See Antonio Cangiano's (@acangiano) blog post for a little motivation: http://antoniocangiano.com/2010/05/14/the-most-important-programming-language- today/ On Saturday, May 15, 2010 03:22:32 pm Abraham Williams 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 -- M. Edward (Ed) Borasky http://borasky-research.net/m-edward-ed-borasky/ @znmeb "A mathematician is a device for turning coffee into theorems." ~ Paul Erdős
