Skip to main content

Posts

Showing posts from May, 2008

First Google Anniversary

Image via WikipediaSeems impossible, but I've been at Google for a year now. I started May 21, 2007, 366 days ago. It's been eventful, and rewarding, and at times exhausting. I'm having an incredible amount of fun and feel like there's no better place to be right now. Also, I'm actually riding my bike to work most days on the Stevens Creek Trail; I have to, to work off the Google food.

OpenSocial RESTful API

For those who were at the OpenSocial summit yesterday, here are the slides from my RESTful API talk:



In a nutshell, the OpenSocial RESTful API is a catalyst that enables participation in a much larger and more complex ecosystem.

XRDS-Simple (Yadis) + URI Templates

In writing up the OpenSocial 0.8 RESTful API spec, I ran up against a discovery gap. Clients know what social network container they want to query (e.g., orkut.com) and they know what kind of data they want to get (e.g., list of friends). An easy way to spec this is to mandate that every site has to support the same URI paths, like /friends/{userid}, and then just concatenate to get a final URI -- http://orkut.com/friends/{userid}. This turns out to be difficult in general; there are existing path conflicts, different server technologies make certain paths hard, etc. It turns out that you need to let containers provide different paths. So, there's a real discovery problem.

Enter XRDS-Simple (aka Yadis), the discovery mechanism used by OpenID and OAuth. It lets a client query the URI http://orkut.com to find out what URI to use to retrieve friends. Perfect!

Except, that /friends/{userid} isn't a URI -- it's a recipe, or template, for a URI. So XRDS-Simple can't …

Public Keys can be People Too

Why not let public keys be people too (by turning them into URIs)? Here's one way, based on RFC 2015:

<link rel="me" href="http://www.abstractioneer.org/" title="My Blog">
<link rel="me" href="data:application/pgp-keys;base64,AHEIJ3334..." title="My Public Key">

And then we hook it into the Social Graph API.

OpenID discussion at IIW2008a

I'm at IIW2008a today and tomorrow. Had a good discussion about OpenID adoption challenges with the usual suspects this afternoon. The full notes will be up on the Wiki soon, a few things that need to get fixed:
OpenID, Please is very cool; but... ironically, I can't sign in to it as http://www.abstractioneer.org/. Needs to get fixed on one side or the other.
The list of barriers to adoption is a lot longer than the list of user benefits! This needs to change.
There hasn't been much push to get client side code to adopt OpenID (Firefox, toolbars, Google Gears, etc.). A big problem here is that it's not clear exactly what such code should do, or whether the standard is sufficient for whatever it should do to work well. This needs to change.And a thought: For RPs, OpenID adds complication to their login system. Unless they're ma.gnol.ia, they still need to build a non-OpenID registration and login system to handle non-OpenID users. Silly idea: What if there w…

Babbage's Difference Engine at IIW