- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Thu, 13 Sep 2007 11:13:27 -0700
- To: "Arve Bersvendsen" <arveb@opera.com>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>, "public-appformats@w3.org" <public-appformats@w3.org>, public-appformats-request@w3.org
- Message-ID: <OFFBB29548.0C473ECE-ON88257355.00617B22-88257355.00641C1C@us.ibm.com>
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. 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. 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. 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. 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. 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. Jon "Arve Bersvendsen" <arveb@opera.com> To Sent by: "public-appformats@w3.org" public-appformats <public-appformats@w3.org> -request@w3.org cc "Mark Nottingham" <mnot@yahoo-inc.com> 09/13/2007 04:30 Subject AM Re: [Widgets 1.0] Automatic Updates (1.0)? On Thu, 06 Sep 2007 05:30:20 +0200, Mark Nottingham <mnot@yahoo-inc.com> wrote: >> Sorry, I don't understand what you mean by "the indirection of a >> manifest". Can you please explain what you mean by the above a bit >> more. > > Just wondering why it's necessary to have a split between the widget and > the metadata in the file (as per your example). A few things to consider: 1. Widgets that are to be updated may not always come from an HTTP source, so there may not be an origin to speak of. 2. On connections where users pay based on traffic, downloading the entire widget to check for version identity is infeasible 3. Widget settings may change between version updates, and an updated widget may not conform to policy for the device (such as an updated widget suddenly requiring network connection where the previously installed version may not be permitted) on which the widget is installed. >> Also, one cannot assume that a widget was always acquired directly >> from a web server: it might be the case that an end-user sends a >> widget to another end-user, say, over Bluetooth. Those widgets should >> still be able to connect back to their point origin and check if an >> update is needed. > > I don't think that affects things, as long as the widget 'knows' what > its URI is. The URI is not always known, as download URI's may for instance be generated by a CMS handling widget uploads, and such it may be ill-suited for being declared in the widget itself. If the URI is not declared, the source of a widget delivered over say Bluetooth, e-mail, MMS or similar may not be known, or possible to derive. It seems though, from this discussion that we need a common and clear understanding of what the requirements for an update mechansim are, before progressing further. Take this mail as initial input for said requirements. -- Arve Bersvendsen Developer, Opera Software ASA http://www.opera.com/
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic19375.gif
- image/gif attachment: ecblank.gif
Received on Thursday, 13 September 2007 18:24:59 UTC