Dumb Clients (and why it's smart to support them)

[Dan Bentley]

I've been working on the RESTUL API python client library.  (http://code.google.com/p/opensocial-restful-python-client , with the caveat that the code is less-than-impressive.)  Some thoughts:

• Wow, XRDS is cool.  It makes it really easy for containers to come up with a new service and launch it in a way that's discoverable.  This is going to be awesome for making fancy libraries that allow questions of the form "what can I do here?"

• Wow, XRDS is complicated.  To do what is conceptually one get can take up to 3 requests (first some container url to find out where the XRDS document is, second to get that document, and a third to actually get the data based on where the XRDS description says it is).

I'm ecstatic to make a python library that allows easy querying of this per-container "what services do you support?" data in a programmatic and pythonic way.  I'm enthused to write a similar library in Java, though worry about having to write two such libraries...  And then there's php, and ruby, and C++...

People *are* going to write dumb libraries that do gets based on string appending for simple requests.  (One of the benefits is that OpenSocial makes it easy to do simple requests that provide enough info to do interesting things.) I think it's worth committing to supporting these dumb clients.

Concretely, I guess I'm proposing that we specify some amount of the XRDS (roughly of the scope of the sample XRDS at section 5 of http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html ) that all containers will support the URLs of.  That is, clients may consider the XRDS for a container to be <this standard XRDS> + <the XRDS fetched from the server>.

This would push work from the clients to the containers.  But the work would be large on the client side and small on the container side.  (I believe; please correct me if I'm wrong, but it seems like it'll be fairly easy to map the common URLs to whatever backend you have.)

Thus, containers would still be free to do whatever awesome new services and mappings they care about.  Clients would still be able to use these new services through reflection on XRDS.  But clients would also be able to do the simple thing and not be unduly hosed due to the caprice of conforming-but-confusing containers.

This email is long enough now, so I'll shut up and see if this bears any further discussion at all.

-Dan

[Christian Scholz / Tao Takashi (SL)]

Hi!

On Wed, Jun 4, 2008 at 1:34 AM, Dan Bentley <dben...@google.com> wrote:
> I've been working on the RESTUL API python client library.
> (http://code.google.com/p/opensocial-restful-python-client , with the caveat
> that the code is less-than-impressive.) Some thoughts:
>
> Wow, XRDS is cool. It makes it really easy for containers to come up with a
> new service and launch it in a way that's discoverable. This is going to be
> awesome for making fancy libraries that allow questions of the form "what
> can I do here?"
>
> Wow, XRDS is complicated. To do what is conceptually one get can take up to
> 3 requests (first some container url to find out where the XRDS document is,
> second to get that document, and a third to actually get the data based on
> where the XRDS description says it is).

I agree on both things.

> I'm ecstatic to make a python library that allows easy querying of this
> per-container "what services do you support?" data in a programmatic and
> pythonic way. I'm enthused to write a similar library in Java, though worry
> about having to write two such libraries... And then there's php, and ruby,
> and C++...

I started such a thing as part of the pydataportability library:
http://code.google.com/p/pydataportability/

Hope to put up some more docs soon. This can parse XRDS Simple to some
extent and creating it is also planned.

I will also have a look at your library.

cheers,

Christian

--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com

Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T

[John Panzer]

I'm out on paternity leave so unfortunately I can only toss a few thoughts out quickly. 

• One motivation for having some kind of discovery is that different containers _have_ to have different prefixes and sometimes domains for the RESTful API, e.g., orkut.com -> orkut.com/social/people/...  Starting from the domain of the container (orkut.com) it's not trivial to figure this out (a lot more trivial than XRDS-Simple of course, but nontrivial).
• It's not clear that containers don't want to segregate traffic off to an api domain (e.g., api.orkut.com).
  
• I think this means that assuming a static XRDS-Simple common base won't work, even if you assume relative paths and no api domain; orkut has different paths than hi5 than myspace than...
• In the common case, there are no additional network transactions to use these XRDS files, since they's highly cacheable.  I'd expect Orkut for example to tell clients to cache its XRDS for weeks or months.
  
• Other standards are already using XRDS for discovery, so it's likely that there are already libraries to deal with it in most languages and possibly it's already incorporated into your client.  Anything that uses OpenID also uses XRDS.  (See for example http://openidenabled.com/files/python-openid/files/python-yadis-1.1.0.tar.gz, though I haven't looked at the code myself.)
  
• Aside: The extension to allow templates,  not just concrete URIs, in XRDS-Simple is highly likely to be incorporated into the base spec when it's finalized (other people want it too).

On Tue, Jun 3, 2008 at 4:34 PM, Dan Bentley <dben...@google.com> wrote:

I've been working on the RESTUL API python client library.  (http://code.google.com/p/opensocial-restful-python-client , with the caveat that the code is less-than-impressive.)  Some thoughts:

• Wow, XRDS is cool.  It makes it really easy for containers to come up with a new service and launch it in a way that's discoverable.  This is going to be awesome for making fancy libraries that allow questions of the form "what can I do here?"

• Wow, XRDS is complicated.  To do what is conceptually one get can take up to 3 requests (first some container url to find out where the XRDS document is, second to get that document, and a third to actually get the data based on where the XRDS description says it is).

Yes, in the worst case.  In the common case (especially for OpenSocial using templates) it's all cached and there's only one request.
 

I'm ecstatic to make a python library that allows easy querying of this per-container "what services do you support?" data in a programmatic and pythonic way.  I'm enthused to write a similar library in Java, though worry about having to write two such libraries...  And then there's php, and ruby, and C++...

The thinking is that this is largely already done, e.g., http://openidenabled.com/files/python-openid/files/python-yadis-1.1.0.tar.gz.  That is, we can draft off of the work done around the OpenID discovery problem to a large extent.
 

People *are* going to write dumb libraries that do gets based on string appending for simple requests.  (One of the benefits is that OpenSocial makes it easy to do simple requests that provide enough info to do interesting things.) I think it's worth committing to supporting these dumb clients.

 

I'm a big fan of trying to support the "View Source Clan".  Such dumb libraries will run into a brick wall anyway when they try to do authenticated requests though. 
 

Concretely, I guess I'm proposing that we specify some amount of the XRDS (roughly of the scope of the sample XRDS at section 5 of http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html ) that all containers will support the URLs of.  That is, clients may consider the XRDS for a container to be <this standard XRDS> + <the XRDS fetched from the server>.

See above -- I don't think there's a single core, static XRDS-Simple document that would work for every container; if you can propose one that'd be great.

Another issue is that not all technologies support all types of URIs as easily.  The 'worst case' is usually a hosted CGI environment, where you _have_ to have something named <path not under your control>/<script name>.cgi, plus query parameters.
 

This would push work from the clients to the containers.  But the work would be large on the client side and small on the container side.  (I believe; please correct me if I'm wrong, but it seems like it'll be fairly easy to map the common URLs to whatever backend you have.)

Google has certain rules