Re: Widgets PAG seeks feedback on Widget Updates spec

On Mon, Jun 29, 2009 at 10:46 PM, Robin Berjon<robin@berjon.com> wrote:
> Hi,
>
> sorry, I hadn't seen that this was also posted publicly.
>
> On Jun 29, 2009, at 20:23 , Arthur Barstow wrote:
>>>
>>> The current Widgets-update Specification
>>> http://dev.w3.org/2006/waf/widgets-updates/
>>> contains in 12.3 a description on how a widget could update
>>> itself by a javascript calling the widget.update() method
>>>
>>> I wanted to know how important this feature is to the group
>>> and how likely it will be that it will find widespread use.
>>> The goal is to assess whether it is worthwhile to circumvent
>>> the patent also for this self-update feature, which will
>>> be a little bit harder than the circumvention for the rest
>>> of the Specification.
>
> My personal and non-legal opinion on this topic is that that feature simply
> does not exist.
>
> It is mentioned in an example which by definition is not normative (section
> 1 Conformance further notes "Everything in this specification is normative
> except for diagrams, examples, notes and sections marked as informative" and
> the section itself starts with "This section is informative.") It is not
> defined by Widget Updates and it is not defined by Widget APIs and Events.
>
> Furthermore my understanding is that this is the only part of the
> specification that could possibly infringe Apple's patent, which means that
> the specification in fact doesn't since that feature is not a part of it (or
> any other).
>
> We can more than very easily drop the example, and in fact the entire
> section since it is entirely incorrect.
>

The purpose of widget.update() is/was _not_ to  "update" the widget in
any meaningful way:

>From the spec "...an author can request that a widget asynchronously
check if a widget has been updated [(i.e., that a new version of the
widget package is available online)] via the widget.update() method,
defined in the Widgets-API specification. This strategy also relies on
the author having declared a update element in the widget
configuration document, as it makes use of the URI to potentially
retrieve an UDD and relay whether an update is available back to the
instantiated Widget. **Actually performing the update is left to the
discretion of the widget user agent.**"

In other words, it was/is a means to for a widget to ask the Widget
User Agent if an update is available from the remote location
addressed by the update element's href attribute (so, really it should
have been called "checkForUpdate()" or "updateInfo = new
UpdateChecker()", which the example begins to elude to). As it says in
the spec, "_actually performing the update is left to the discretion
of the widget user agent._"

So, to try to be crystal clear, here is how I thought this would work
wrt widget.update() when I created this thing (and more or less what
is eluded to in the spec):

1. Widget is running.
2. At some point in time, widget calls
widget.update(callBackFunction). (Note that this is just one of the
three strategies for _checking for the availability of an update_ (no
actual "updating" is performed) - other two strategies are handled
exclusively by the widget user agent, see spec).
3. Iff an <update> element is declared in the widget's config doc, and
has a valid href attribute, the Widget User Agent MAY check for
changes in the update description document (using http responses AND
checking the content of the UDD for changes).
4. If an update is available invoke callBackFunction with an object
describing the update.
5. If no update is available, invoke callBackFunction with an object
describing that no update is available.
6. Author notifies, via some modality (e.g., a sound, an alert, or
some visual means left up to the author), that an update is or is not
available for the widget.
7. The end user quits the widget.
8. The end user requests from the Widget User Agent to update the
widget (if update is available).
9. The widget user agent downloads the updated package from the
location identified by the  description document.
10. The widget user agent checks authenticity of package. If
everything is ok, then overrides the existing widget, but maintains
preference data. User agent MAY notify the end user that the widget
has been updated.
11. End-User restarts the widget.

So, I don't what would be achieved by removing widget.update() as it
doesn't actually do any "updating". If anything, we need to redefine
widget.update() to make it more useful and powerful.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 30 June 2009 09:25:39 UTC