> i understand that you have to tow the line. i agree with it — at least in
> principle. i like oauth. i understand it. i *want* to put it in my app.
> aside from my desktop client, i released an open source oAuth solution:
> http://thurly.net//5nl
> yet, of the prominent mac clients (tweetie, twitteriffic, socialite, beak,
> bluebird, kiwi) only one is currently using oAuth. the reasons are painfully
> obvious and have been discussed here and elsewhere ad nauseum:
> http://groups.google.com/group/twitter-development-talk/search?hl=en&group=twitter-development-talk&q=oauth+desktop&qt_g=Search+this+group

honestly, i actually resent the "i understand that you have to tow the line"

i feel there is a lack of user education going on to explain to users why
oauth is actually better for the user -- for a list of said reasons, please
see http://apiwiki.twitter.com/OAuth+Example+-+Ruby.  additionally, i
understand that simply putting up a dialog box with two text input fields is
easier to code than writing software that manipulates a browser, and that is
why a lot of applications do that.

as i see it, and having written software against the Twitter APIs (ate our
own dogfood), what's missing are the following two things (please add to the

   - when using oauth, a good way to integrate with third party services
   that also use twitter credentials (yfrog, twitpic, URL shorteners, etc.) --
   this is "delegation"
      - http://twitter.com/twitterapi/status/6743938510
   - a good workflow for desktop apps -- specifically, desktop applications
   that have access to a browser.  i am -not- talking about rich environments
   that do not have access to a general purpose browser (set top boxes, game
   consoles, etc.)

what i would rather see, and what i'm interested in fixing, are those two.

Raffi Krikorian
Twitter Platform Team

Reply via email to