Monday, July 7, 2008

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 :)

Monday, February 4, 2008

Widgets, Xiclets and the REST

It seems Fabio Forno and Pedro Melo are also brainstorming on some kind of "widget-technology" for jabber, and the same applies to me. I've written several articles in the theme, see:

Why xmpp4moz needs to be a standard: What's wrong with XEPs?
XMPP services as OpenSocial providers
Meebo invented everything for us in 2007(?!)

Why do we need such? Let's see:

  • HTTP is one of the most succesful protocols

  • It has the following extensions currently in use:

    • HTML 4.01 (or XHTML 1.0) for presentation

    • CSS 2.0 for design

    • ECMAScript 3 (JavaScript 1.6) for interactivity (with an included DOM API, and with the lack of threads, therefore it should use asynchronous requests)

See? Nothing else. No JSRs, no XEPs, no "MAYs", just these three.

Does it solve all problems? Not always, but mostly. Does XMPP solve all problems? Not yet.

Now let's get back to the topic specifically.

The thing is about code mobility, and now we can safely reference to the original REST article (which isn't as bad as restafarians usually are):

Let's have an application, residing on a certain location (URL), being it chess, or a flash-based videoconferencing/VoIP tool; of course, for interactivity, at least two instances should be run, one at each participating user. We can use either the fact that modern IM-clients use an embedded browser to display conversations (official AIM, Y!M, WLM; Adium), or some kind of integration between the IM-client (eg. pidgin) and a browser (eg. firefox). What could this look like?

The design issues we met are:

  1. Features provided by XMPP

    • (RealTime) Communication channel between two application instances from the same source
    • (RT) Communication channel between an application instance and the participating users
    • RESTRICTED? Presence information of the participating entities (users + bots)
    • STRICTLY RESTRICTED: Roster information + all contacts' presence of the user

  2. Features provided by HTTP

    • Remote script inclusion (like: Google Gadgets)
    • Developers MUST be able to write XMPP-supported applications in pure web-style (eg. PHP scripts)
    • It SHOULD be easy to adopt already written applications for the new platform, either which uses real-time communication and those who aren't

  3. Features derived from browsers:

    • Ability to run javascript applications
    • Ability to display XHTML + CSS
    • DOM API (perhaps E4X as well? at least, at a later time)
    • Sandboxing and cross-domain code execution
    • Some kind of interaction between the XMPP client (which SHOULD be able to be a web-based client too!) and the application

Restricted features could be accessed if certain security checks are met (like: the page is from HTTPS, signed by an acceptable authority, like the enterprise running the XMPP infrastructure, or an official XMPP extension); This was done for years with java applet/midlet technology.

Our current example is a Go (simpler than chess) client which should be written in pure PHP + JavaScript (not because we ourselves cannot use more sophisticated, but it's the lowest entry barrier)

Another good example is whiteboarding, it's done such way in Yahoo! Messenger.

We'll see if we could extend it further.

Hope we could meet at DevCon and have a conversation about that (but it shouldn't stop you to comment :)

Wednesday, January 16, 2008

Open Source Nights presentation

I presented a few hours ago on Open Source Nights, hosted by my long-time friend and ubuntu advocate Szilveszter "Phanatic" Farkas about jabber.

I quickly translated the slides, you can read them in English here or in Hungarian here.

All in all, it was a good evening, hope it will bear us some deployments, or at least, jabber users :)