Imagine for a moment that Twitter implemented the OpenSocial Data APIs to sit alongside their own API. We'd have:- - AuthSub instead of HTTP AUTH - Atom instead of RSS - GData People API instead of the Friends calls - AtomPub instead of the calls for posting status Pewrhaps then there was a concerted push by all the Twitter client apps to work with the new API. Now imagine that Jaiku, Pownce, MySpace and anything else that has a Twitter-like status function did exactly the same thing. Those new client apps could then offer a simple UI choice to the user. Which Status service do you want to work with? Or perhaps you'd like to work with all of them? And we'd see all those huge numbers of Twitter Apps and Mashups work quickly with all the Status type services. There's something huge here, isn't there? But then you get into the horrible sticky details. - There is no example of the Data APIs yet and the specs are in flux. - Orkut has no Status field so there's no incentive for Google to add this area into the specs - Which means each OpenSocial Service that does have a status field potentially ends up implementing it in their own way. - And unless we impose standards on endpoint URLs, we'll need auto-discovery standards as well. eg. is your profile always at /feeds/people/me on every site? |
[ << The OpenSocial Data APIs and implications ] [ An answer to Gabe Wachob: Google's Open Social: The missing pieces? >> ]
[ 06-Nov-07 8:09am ] [ Google , opensocial , twitter ]