Re: [widgets] Comments on API spec: Storage areas and Origin

continuing on from last email....

2009/9/16 Scott Wilson <scott.bradley.wilson@gmail.com>:
> I haven't seen any comments yet on this issue?
> (This may just be me misunderstanding the intended meaning of "origin" in this context.)
>
> On 19 Aug 2009, at 11:42, Scott Wilson wrote:
>
> sue:
>
> 5. Storage Areas
> "A storage area is a data-store that is unique for the origin of a widget, which a user agent can use to store string-based key-value pairs."
>
> The storage area must be unique to the instance of a widget. Otherwise this will lead to widget instances overwriting each others' preference settings, or exposing personal preferences to other users who happen to be using the same type of widget. (There's a discussion of this on the list somewhere).
>

Yes, this is certainly true in a HTML context.

> However, given the definition of origin in the document, the current text may be a problem:
>
> "The universally unique identity of a widget represented as a URI, established via the rules defined in the [Widgets-URI] specification."
>
> Now by "widget" do the spec actually mean the widget instance, or what you might think of as the widget's "class" or prototype?

Widget instance is always the assumption. Yes this needs to be more
clear in the spec. However, this does not solve the identity crisis.

> The latter would seem to be the case given a read of the Widgets URI scheme draft [1], in which case, the Origin is not going to work for associating a storage area unless the UA is single-user and doesn't allow widgets to be instantiated multiple times.
>

This is not necessarily true (or how I had envisioned it would work).
As with my last email, "instances" would have a unique authority.
However, I'm now fearing that this is not correct.

> (E.g. Apache Wookie (Incubating) mints a UID when a widget is instantiated for a particular user in a particular application context (e.g. user "bob" puts the "weather" widget onto their "profile page"), and uses this UID to associate a storage area with the widget instance. The widget id URI as found in config.xml->id is used along with application context and user data to generate the hash for the UID. Now, is Wookie's UID the "origin" as far as A&E is concerned, or is it the canonical widget id?)
>

The widget id declared in the configuration document has no
relationship whatsoever to the instance identifier (or the unique
"origin" of a widget). Consider the widget id as the canonical "name"
of the widget, which is persistent across versions.

> So either "origin" needs clarification as referring to widget instances, or storage areas need to be defined in terms of instances and not necessarily the origin - in which case the dependency of the A&E spec on [1] can be removed.
>

Agreed. This will require some thought. Either:

1.  each instance gets its own identifier through the widget URI scheme.
2.  each instance gets its own identifier as an implementation detail
- however, the storage is bound to the unique identifier.

In any case, it's pretty clear what we are trying to achieve in terms
of requirements. A specification must:

1. provide a means to (implicitly) identify an instance of a widget.
2. application preferences must only be bound to that instance (thus
not shared across two running widgets).

In 1, I say "implicit" in that I don't see any real use case for the
author accessing the actual identifier.

It would be like, in JavaScript, doing the following:

widgetA = {};
widgetB = {};
alwidgetA === widgetB; //false

Kind regards,
Marcos

> [1] http://www.w3.org/TR/widgets-uri/
>



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

Received on Thursday, 24 September 2009 21:38:26 UTC