Boston

Recently got back from the Boston Face 2 Face meeting. While there I visited MIT, Nokia Research, and France Telecom (Orange) research labs. Check out the photos on flickr.

Widgets 1.0 responses and thoughts

Responses to the Widgets 1.0 spec on the web have been mixed, but mostly positive with a few negative comments here and there. There have been some positive responses, like the one on Ajaxian. The brief article on Ajaxian seems to clearly capture the point of the spec:

Everyone and their mother have created their own widget specifications, and now as a developer you need to make choices. Do you want it to work on Dashboard? Google? MSN? Yahoo!?
If the big hitters supported this widget standard then we could write once, widget everywhere. Kinda 🙂

And another really good point they make is that…

This standard will live and die by the support that it gets.

Dare Obasanjo wrote a fairly negative blog entry about the Widgets spec seems to kinda miss the point (and Mark Baker points that out in the comments), because he seems to think that Widgets 1.0 is trying to address web page embedded widgets, which it is not.

Arve Bersvendsen, who edited the very first versions of the Widgets 1.0 spec, took time to briefly blog about the widget spec; and so did Anne van Kesteren (currently the other editor of the Widgets spec), stating in his blog entry about Widgets 1.0 that for some time I thought widgets were the latest marketing trick and pretty useless. Now I think they can actually be really useful (and fun) for creating simple applications using HTML, ECMAScript and CSS. The website Musings from Mars also thought that Widgets 1.0 was a good idea, saying let’s hope the world came settle on a standard that would let developers write widgets that would work on all the various platforms (Yahoo, Apple, Opera, Google, and, yes, Microsoft).

It seems that in general people get what Widgets 1.0 is all about. For those who don’t, lets be clear. The purpose of the spec is (IMHO):

  1. stop fragmentation of the Widget development space, particularly in relation to metadata and the APIs.
  2. to provide a standardized way to package, sign, code, and record metadata about widgets. The theory being that, if adopted by vendors, you could write a widget once and run it on any conforming widget engine (Yes! the same as Java applets). Of course, this second point is very complex (or screwed!) because of the API problem, which is the greatest challenge for the standardization of widgets. I return to this massive issue later.

I think the cause of confusion has partly been the name “Widgets 1.0” and the lack of historical context around this spec. I guess this is why the original requirements document I wrote was named “packaging client-side web applications”. Even though the title made sure that very few people knew what the hell i was talking about, the title of my document captured (part) of the problem well… but capturing the problem well doesn’t help if people don’t know what the hell you are talking about. However, the Widget spec is wider in scope and so is the now renamed “Client-Side Web Applications (Widgets) Requirements” document. As I already discussed above, the scope of both documents now covers five issues surrounding widgets:

Continue reading Widgets 1.0 responses and thoughts

Web Application Packaging

This week I will start looking at how applications are packaged and distributed on both the client-side and server-side. Application packaging is basically the process of bundling an application into some kind of archive format (like a zip file) with instructions (usually in XML) for a host runtime about how to unpack that application and execute it. Application packaging is used on both the server-side, as is the case with J2EE WAR files and EAR files and .Net’s Cab files, and the client-side as is the case with Widgets such as those from Yahoo! and Opera. In this entry I will start comparing the different ways that companies package applications for deployment. The purpose of this excersise is to find the optimum way to package an application that is both lightweight enough for the client-side, and strong enough to cope with larger enterprise size applications on the server-side. This entry will serve as a foundation for a W3C Note on application packaging. It will be published as part of Web Application Formats Working Group. The Latest Draft of the document is available from the w3c dev website. (Please note that I am still working on this entry).
Continue reading Web Application Packaging