W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 12 Feb 2009 11:19:59 -0800
Message-ID: <4994765F.3020707@sicking.cc>
To: timeless@gmail.com
CC: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps@w3.org, Ian Hickson <ian@hixie.ch>

timeless wrote:
> I think the problem here is that there's too much syntactic sugar in
> sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL,
> and maybe Hixie or others could help to address it).
> 
> I can easily replace the object (window.sessionStorage={})

The sessionStorage property is readonly so that won't work.

> but I
> can't be told when my sessionStorage is decorated by a new property,
> because that's not something which is available to JS (gecko has
> __noSuchMethod__, but there's no watch(sessionStorage, "*", feedback).
> 
> If there was a way for js objects to be told about property writes
> then for the most part, they could replace a host's
> sessionStorage/localStorage with their own object and do what they
> need.
> 
> Today, if the HTML5 sessionStorage/localStorage objects relied on
> (sugar-free) methods only, they wouldn't have a problem. -- No, I'm
> not advocating this.

Things like watch points aren't really defined if they should work when 
it comes to host objects I think. And if we used an API like 
setProperty/getProperty they certainly would not work.

So I don't think the problem here is with the specific API localStorage 
uses either. But rather with the fact that Scott is trying to deploy a 
widget implementation in an environment where he is restricted about 
what the APIs he is implemented are called.

I think in this instance though the problem can be worked around by 
adding event listeners to the Document listening for 'storage' events. 
That can be used to then save the data server-side.

/ Jonas
Received on Thursday, 12 February 2009 19:21:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT