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

On Wed, Feb 11, 2009 at 1:54 AM, Scott Wilson
<scott.bradley.wilson@gmail.com> wrote:
> 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...)

I have to admit there is a large part of the above that I didn't
follow at all. I'll ask you about the specifics if it turns out it
matters.

I take it you couldn't simply let users use localStorage directly
since then if they opened the widget in another browser their stored
items would be gone? This is why you want to back up the API with
server side storage, right?

But even if we introduce a new API called .preferences, won't you have
exactly the same problem once the browser that you run in add support
for the widget APIs? I.e. once IE or Firefox adds support for running
widgets natively, and implement .preferences backed by its own storage
you will no longer be able to deploy your own preferences support in
those browsers?

It sounds to me like the problem isn't with a specific API, but rather
that you run inside an environment that you don't have needed control
over. What's worse, it's an environment that is likely to collide with
all the APIs that you are trying to support.

I don't really know what solution to your problem is. However it seems
wrong to me to adjust the widget specifications to accommodate your
constraints if these adjustments will not help you in the long run
anyway.

/ Jonas

Received on Thursday, 12 February 2009 01:15:17 UTC