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

Hello.

I'm trying to "stress" a bit the current implementation of "preferences
storage", comparing it to the LocalStorage.
I see that a "preferences" array was introduced, but this araise another
problem.
A "Javascript Array" it's NOT a map of "key/value" pairs. This means
that the preferences will have to hold only the "values".
This looks a bit "incoeherent" with the idea of having preferences
stored as "key/value" pairs. Doesn't it?

I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but equivalent
methods.
This means to modify slightly the "widget" object introducing stuff
like:
class widget {
...
	long preferencesCount();
	
	string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
	
	string getPreference(string key);
	
	void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
	
	void removePreference(String key);
	
	void preferencesClear();
...
}

This ensures "enumeration" and some "utility" methods that can become
handy (like a "clear" and a "count").

What do you think?

Best Regards

---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, R&D UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demarino@orange-ftgroup.com


This e-mail, and any files transmitted with it, is intended only for the
use of the person/s or entity to whom it is addressed. If you are not
the intended recipient (or authorised to receive information for the
intended recipient) you must not use, disclose, copy, print or rely on
this e-mail. If an addressing or transmission error has misdirected this
e-mail, please notify the author by replying to this e-mail and delete
all copies of this e-mail.  Thank you.

France Telecom R&D UK Ltd is a company registered in England and Wales
with company number 4193379. Our registered office is Minerva House,
Montague Close, London, SE1 9BB.

-----Original Message-----
From: public-webapps-request@w3.org
[mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
Sent: 12 February 2009 19:20
To: timeless@gmail.com
Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage


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 Friday, 13 February 2009 16:55:37 UTC