I'll just briefly disagree with you about point 2. OAuth does not require that you have a browser available. With Twitter supporting xAuth your desktop or mobile application can take a persons username and password and exchange them for an Access Token for accessing protected resources via OAuth without ever firing up the browser.
You can find out more about twitter and xauth at http://dev.twitter.com/pages/xauth I think you are missing the point as to why twitter don't want web client to use the user streams right now. Much fewer people use desktop applications than use mobile or web applications. If you upgrade your desktop app to use the user streams then all of your customers have to upgrade their app, which will happen slowly over time. If you upgrade a web app all of your clients get upgraded all simultaneously. It sounds like it's purely a capacity issue at the moment. Michael Brunton-Spall Developer Advocate guardian.co.uk On 16 May 2010 06:42, M. Edward (Ed) Borasky <zn...@borasky-research.net>wrote: > 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 > Please consider the environment before printing this email. ------------------------------------------------------------------ Visit guardian.co.uk - newspaper website of the year www.guardian.co.uk www.observer.co.uk To save up to 33% when you subscribe to the Guardian and the Observer visit http://www.guardian.co.uk/subscriber --------------------------------------------------------------------- This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News & Media Limited A member of Guardian Media Group PLC Registered Office Number 1 Scott Place, Manchester M3 3GG Registered in England Number 908396
