- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 25 Sep 2009 00:37:35 +0300
- To: Scott Wilson <scott.bradley.wilson@gmail.com>
- Cc: Marcin Hanclik <Marcin.Hanclik@access-company.com>, "public-webapps@w3.org" <public-webapps@w3.org>
2009/9/23 Scott Wilson <scott.bradley.wilson@gmail.com>: > Hmm, I raised this one too. > I can't see how the origin handles instances exactly, and the concept of "origin" doesn't seem all that relevant to our implementation anyway - it looks more like something for browser makers to worry over? > Why is "origin of a widget" preferable to "instance of widget"? Admittedly, I'm also confused:( My understanding was that the origin of the widget made it unique. This assumption was based on the authority part of a widget URI being a UUID. We may need to fall back to traditional instance identification instead of relying on the origin. However, the Widget URI scheme palms off "origin" to the type of the start file (i.e., if HTML5, then use HTML5 rules for deriving "origin" from the widget URI; If SVG, the use the SVG rules to derive the origin, and so on.... However, it is unclear if, for instance, SVG knows how to do that). I've CC'd Robin to clarify. > This could be important as some conformance statements relate to the concept, e.g: > > Upon getting the preferences attribute, the user agent must return a Storage object that represents the storage area for the origin of a widget. > > If "origin of a widget" is not a sensible concept for the UA (as opposed to widget instance), does this fail conformance? How would you test for it for the UA anyway? > Testing is easy: run two widget instances from the same kind (e.g., two clocks), and make sure that the preference for each widget don't interact (again, based on the assumption that origin makes them unique). Clock A: origin -> widget://abc123/ Clock B: origin -> widget://foobar/ I agree, however, this breaks down when using HTTP because you need to use either many iframes (potentially different origin to host document, but same origin for multiple instance) or a div (same origin as host document). Hence, I we still require a solution for establishing instance identity. Kind regards, Marcos > On 23 Sep 2009, at 17:10, Marcos Caceres wrote: > > 5.4 > > How to handle multiple instances of the same widget? > > As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences. > > No, it's not important. They are bound to the origin of a widget as > defined in WURI, and the origin of a widget is universally unique. > Hence, preferences are unique and not shared. > > > -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 24 September 2009 21:38:21 UTC