Google took the API step

Just to remind: even if nobody seemed to care after my controversial talk on XMPP Summit this year (not that most of you believed such at all), Google took the API step.

(For a rant on APIs, see my previous post and the ones listed at the beginning of that)

I know SamePlace was much before this, but, with all the credits to Massimiliano, GTalk has a much larger user base.

Now, what we need is a standard API above Meebo, SamePlace, and this stuff, like Ajax did for the XMLHttpRequest implementations

Active resource representations - aka OEmbed

(Note: this isn't a jabber-only posts, although one of the earliest implementations is in Google Talk Gadget, and the jabber community could benefit from this in general)



PHP-OEmbed project page

Remember when the newly introduced Google Talk Gadget displayed Youtube videos instead of showing their links? That's what I call "active resource representation", because it represents the given video more [inter]actively than the pure link - which is hardly showing anything in the case of youtube.

I believe that a resource usually can be equally represented in a small place: there's no need to load a full page to view a youtube video or a flickr photo, but there isn't need for it to look at a person's social network profile, to accept/reject a calendar invitation, etc - and all of these have URLs nowadays. These technologies could be used in e-mail systems, forums, and chat clients.

What OEmbed does, is that it tries to provide metadata about a certain resource found at the given URL. That is: you send the link of a flickr photo, and you get an XML or JSON-formatted structure back. While it can be argued, that these could be / should be / in an ideal world, would be solved by HTTP headers, this is not the case, and this solution isn't as bad.


I tried to do a server-side PHP framework, which talks the OEmbed protocol for clients to consume, however, it makes you be able to create non-oembed compatible wrappers too (the perfect example is youtube, of course). This could be used in a web-client, given that it talks back javascript to you.

Currently, it can handle (proxy) any OEmbed provider (given that you enter their respective address into the providers.xml file), and it has a Youtube provider, which uses some not-so-official part of the "official YouTube Data API". New providers can be added by looking at the provider API - oh, and there's no error handling yet, so you could understand the code :)

Note: I extended OEmbed protocol a bit, namely:

• There could be a description field for every OEmbed-entity (handy for tooltips)


• There could be a duration part (in seconds) for video embeds


• The original resource URL could be in the data response

Oh, and Flickr: please add thumbnails! Thanks :)