- From: Arve Bersvendsen <arveb@opera.com>
- Date: Thu, 13 Sep 2007 13:30:53 +0200
- To: "public-appformats@w3.org" <public-appformats@w3.org>
- Cc: "Mark Nottingham" <mnot@yahoo-inc.com>
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/
Received on Thursday, 13 September 2007 11:31:06 UTC