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 <t...@w3.org>
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 <t...@w3.org>
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/
