Re: [Widgets 1.0] Automatic Updates (1.0)?

Hi Jon
On 9/14/07, Jon Ferraiolo <> wrote:
> Hi everyone,
> After thinking about this for a few weeks, my opinion is that the Widgets
> 1.0 specification should steer clear of features around automatic updates.
> The first-order issue is just getting the industry to work towards a unified
> approach to achieve a write-once, run-anywhere benefit such that widget
> developers can produce a component that will work across many different
> platforms. IMO, automatic update is in the area of nice-to-have features
> (bells&whistles) and makes more sense in a second technology wave after the
> first wave has achieved some momentum in the industry.
I've personally received numerous off-line requests for automatic updates
(AUs), particularly from enterprise users. I don't think AUs are "bells and
whistles", and my position is that it should be a fundamental part of
widgets: eg. If I discover that my widget is not interoperable with platform
X, then I can put out an automatic update to address that problem; hence AUs
will help with "write-once run-anywhere" model you describe. To not have a
model for AUs impoverishes the Widgets 1.0 [1] work compared to current

Also, if widgets are to leverage HTML/CSS/JavaScript as the UI language,
then all the cross-platform issues associated with HTML come as baggage
(because, most of the time, widget user agents will leverage browsers that
don't fully interoperate). Those problems cannot be solved by this working
group (hence we have HTML5). The best WAF can do is recommend a set of
technologies to implementers that will meet the requirements desired by
vendors and users [2].

> Instead, it is more advisable to wait for some of the early-adopter
> gorillas to implement and deliver a simple widgets standard and let them
> make progress on de facto standards for automatic update and then (down the
> road) attempt to codify into a standard the technology approaches that have
> proven to work.
Hence we have looked at FireFox's Addons and Yahoo!'s Widget Engine's update
models. As far as I can tell, Firefox's solution has been stable for a
number of years. If my assumptions are wrong, then please send me some
pointers. If there are other HTTP-based solution I should be researching,
please let me know.

There are likely to be various complexities around automatic update that
> will only become apparent when operating in the real world contexts. The
> thrust of the Widgets effort should be to produce a standard that is as
> simple as possible in order to accelerate industry adoption.
I agree in as far as you are talking about a separation of concerns: widgets
and a general model for AUs. I'm willing to develop and edit the AUs model
separate from the Widgets 1.0 specification (which is what I proposed at the
start of this thread). Widgets can then use AUs independently of the Widgets
1.0 Specification and Widget User Agents may support an Automatic Updates
Specification. I personally don't like that solution because I think all
Widgets User Agents should support AUs, but I could live with it.

> In fact, I would drop the ZIP packaging from version 1 and auto-discovery
> features, also. Most likely, the "less is more" approach is likely to have
> the best chance for success.
A while ago you suggested WAF use OCF as the widget packaging format [3] .
We have adapted much of widgets 1.0 specification around the Zip conformance
requirements listed in OCF [4]. Now you are suggesting we drop Zip all

The Widgets 1.0 Spec definition of a widget:  "Widgets are a class of
client-side web application for displaying and/or updating local or remote
data, packaged in a way to allow a single download and installation on a
client machine or device." Widgets 1.0's definition of a widget explicitly
calls for packaging. Please explain what constitutes a widget without a
package? How do I send you my unpackaged widget, say, over Bluetooth to a

> Over in my world (OpenAjax Alliance), there is a lot of discussion about
> mashups. There is clearly a major technical overlap between installable
> desktop widgets and mashup components. I would expect that widget developers
> would like to produce a single component that works within both widget
> engines and mashup engines. As a case in point, there are paths by which
> Google Gadgets can work within mashup environments (e.g., IBM's
> QEDwiki/Info2.0) and within Google Desktop. I haven't seen evidence that the
> Widgets 1.0 effort is taking mashup scenarios into account sufficiently.
> This brings us full circle back to automatic update. There are likely to be
> some update complexities if a widget has to go through the mashup container
> for various proxy services.
In technical terms, please define exactly what a "mashup" is and please use
a real example that relies on a web browser (eg. Mash-up information from
where a book was published from Amazon's dataset with Google maps or
something similar). Also, can you explain what a "mushup component" is in
the same technical terms? I ask you to do this for two reasons:

Firstly, the WAF community needs to comprehend what the OpenAjax Alliance
understands a mashup and component to be (By technical terms, I mean a list
of RFCs or W3C Specs, or Software, or Scripting languages that are involved
in this "mashup" process, and exactly what role they play in "mashing up"
the data on the client-side).

Secondly, define exactly what technologies/requirements are not currently
listed by either the Widgets 1.0 Specification or the Widgets
1.0Requirements document to achieve a "mashup".

If we are not meeting some particular business use case, WAF needs to
clearly understand why and how? I've had exactly this issue raised by
another member of the OpenAjax Alliance community; however, he was unable to
provide me with any of the technical detail we need. Hopefully you can
enlighten us.

> But all of this discussion of features isn't as important as which
> companies are on board with this effort. Which vendors have committed to
> implement Widgets 1.0? Are Microsoft, Apple, Google and Yahoo involved?
> Has Nokia committed to implemeting this spec? If the big guys don't
> implement Widgets 1.0, then the widget developers will focus on the
> formats that the big guys use instead of Widgets 1.0.
> Last time I looked all the mayor players were part of WAF. However, I
think it is premature to be asking vendors to commit to something that is in
its infancy. I would expect that once the Widgets 1.0 Spec reaches CR, then
vendors may choose to opt-in if the specification meets their business
needs. Before any of this can happen, we need a solid spec that vendors can
see real business value in and that solves real problems.
 Kind regards,


Marcos Caceres

Received on Monday, 17 September 2007 03:46:12 UTC