i think i've failed to connect and instead i've offended you. i'm
sorry, it wasn't my intention.
i feel there is a lack of user education going on to explain to
users why oauth is actually better for the use
i'm just not sure how this is pertinent to anything i wrote. as i
said, i want to use oAuth -- i think we all do. you're preaching to
the converted. :-)
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 said, i've already gone through the trouble of releasing an open
source implementation of oAuth for Mac OS X -- so your hyperbole kind
of misses the mark. myself and others have already done the hard work
and released open source to help make it easier for the rest to come
along.
i don't think it's the required effort that is preventing desktop apps
from migrating -- it's just the user experience.
let me start again.
i wanted to show that the current oAuth flow for desktop apps is
preventing many desktop apps from moving to oAuth.
i did this because your offhand "I don't know," response seemed to
indicate that the announced changes were not getting much priority in
the api.
i wanted to help you see the importance of these changes for desktop
clients.
i'm really excited about the changes. i'm dying to start working on
them. i'm committed to releasing an open source solution to them as
soon as they come out.
i hope you're as excited as i am.
if it's unclear on exactly which changes i'm talking about. it's the
ones that you mentioned in this post:
http://groups.google.com/group/twitter-development-talk/msg/18b38db599f6ad98?hl=en
thanks,
isaiah
On Dec 30, 2009, at 5:53 AM, Raffi Krikorian wrote:
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" statement.
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 list):
• 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://groups.google.com/group/twitter-development-talk/browse_thread/thread/ac5632554444efcb/951ee32ec9cea3a8?lnk=gst&q=delegation#951ee32ec9cea3a8
• 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
http://twitter.com/raffi
