Re: Storage and widgets
I think perhaps the underlying assumptions may vary according to the type of UA? However, I think even on a single-user O/S (e.g. mobile) or in a sandboxed user context you would still want to maintain storage of preferences on a per-instance basis. For example, if you had more than one instance of a single widget, you'd most likely want this as you needed to have different configurations for each (e.g. two single-feed RSS widgets, each one with a different feed). If widgets shared a single preference state by type then this wouldn't work. S On 25 Apr 2009, at 15:37, Thomas Roessler wrote: It's probably worthwhile to be more explicit about the requirements here: In Guido's and my discussion, we assumed a requirement to have persistent storage that might be available to *all* instances of a widget. That's different from per-instance storage which could indeed be solved easily within the currently proposed framework. I'm not sure whether the current requirements document actually answers this question. -- Thomas Roessler, W3C On 24 Apr 2009, at 18:02, Scott Wilson wrote: In our system when a widget is instantiated we generate our own instance hashes which we append to the widget URL as a parameter, and our Storage implementation uses this parameter when it needs to make a request back to our prefs web service to load preferences, or to set a preference. I imagine any UA would put a similar mechanism in place in its Storage implementation to sandbox the preferences for widget instances; does that need to be specified? On 24 Apr 2009, at 09:37, Arve Bersvendsen wrote: On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: Guido Grassel is reminding me that the HTML5 storage API keys off origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Re: Storage and widgets
It's probably worthwhile to be more explicit about the requirements here: In Guido's and my discussion, we assumed a requirement to have persistent storage that might be available to *all* instances of a widget. That's different from per-instance storage which could indeed be solved easily within the currently proposed framework. I'm not sure whether the current requirements document actually answers this question. -- Thomas Roessler, W3C On 24 Apr 2009, at 18:02, Scott Wilson wrote: In our system when a widget is instantiated we generate our own instance hashes which we append to the widget URL as a parameter, and our Storage implementation uses this parameter when it needs to make a request back to our prefs web service to load preferences, or to set a preference. I imagine any UA would put a similar mechanism in place in its Storage implementation to sandbox the preferences for widget instances; does that need to be specified? On 24 Apr 2009, at 09:37, Arve Bersvendsen wrote: On Thu, 23 Apr 2009 20:17:07 +0200, Thomas Roessler wrote: Guido Grassel is reminding me that the HTML5 storage API keys off origin. Thy means another wrinkle or the uri scheme/origin discussion. Note that only the instantiations of storage, through the localStorage and sessionStorage, are using origin. The storage interface itself does not, so I do not see any immediate consequences with regards to preferences or any uri scheme discussion. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
RE: [DOML3Events] ACTION-267 Proposal for event iterator
Following up on last year's discussion on adding support for querying DOM elements about already registered event handlers: Travis Leithead wrote on Apr 09, 2008; 08:07pm > In considering a design for the event iterator (allow devs > to enumerate what events have been _added_ via > addEventListener to a given object), I looked at two general > approaches: > > 1) Defining a new collection on every object that supports > the EventTarget interface > 2) Defining a 'getNextEvent' function for every object that > supports the EventTarget interface > 3) Defining a function that returns a static/dynamic list of > event handlers for a given object that supports the > EventTarget interface Action page: http://www.w3.org/2006/webapi/track/actions/267 Mail thread view on nabble: http://www.nabble.com/-DOML3Events--ACTION-267-Proposal-for-event-iterator-t d16593177.html#a16691378 Was any consensus ever reached and what's the status of this suggestion now? Personally I think this feature is a very natural part of the DOM API and believe there needs to be very good reasons not to include it. Best regards Mike Wilson
