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): http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

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