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

Hi Jonas,

We run the widgets from a server, which a web application renders into  
the browser window using iFrames (a typical "web widget"  
architecture). Each widget in its iFrame calls the Widget API getPref/ 
setPref methods, which are implemented in a locally injected JS  
library. This library implements the get/setPref methods as AJAX  
requests back to the server.

If the widget used the LocalStorage interface, the server would not be  
engaged in the storage process, as localStorage is implemented by the  
browser itself. We might then run into issues where the same widget  
was instantiated for different users in different contexts - currently  
we issue an opaque identifier to each running widget instance that  
enables the server to keep the user preferences separate - though  
perhaps this could be picked up by the localStorage implementation if  
it used the querystring as part of calculating the storage scope.   
We'd still get an issue, however, of users losing all their widget  
preferences if they accessed them from a different device, or a  
different browser on the same device, which would be annoying.

(Admittedly this is not an issue for single-user environments...)

However we could get around this by having the Widget object return a  
handle for an object that implemented the HTML 5 Storage interface -  
in our implementation this would then be an object we define in our  
injected JS library (using AJAX once again), while in other  
implementations this could either be the localStorage instance, or a  
facade that maps the calls onto another storage method (e.g. Apple  
CoreStorage).

It may also be worth exploring having a separate mechanism for  
handling access to arbitrary container-managed attributes (for  
example, the current user's display name, role, or other profile  
information) in a similar fashion; currently we use preferences to  
handle these as well.

(NB: "web widgets" are not explicitly within the scope of the W3C  
Widgets spec, but  I think it would be good to provide solutions which  
don't rule them out either.)

S


On 11 Feb 2009, at 02:54, Jonas Sicking wrote:

> On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson
> <scott.bradley.wilson@gmail.com> wrote:
>>
>> This is a pretty radical change; I can certainly see the logic of  
>> it in
>> terms of reducing spec overlap. However, it does presume that  
>> semantically a
>> widget preference is the same as client-side storage. In our  
>> implementation,
>> storage is definitely server-side, so this mechanism would not  
>> really work
>> for us.
>
> I'm not sure I understand the difference. Can you describe why your
> implementation wouldn't be able to store the HTML5 API server-side?
> Are there any changes we could do to the HTML5 API that would allow a
> server-side back-end?
>
> / Jonas