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 

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:


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

Reply via email to