On Thu, 06 Sep 2007 05:30:20 +0200, Mark Nottingham <[EMAIL PROTECTED]>
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/
