- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 11 Feb 2009 17:14:39 -0800
- To: Scott Wilson <scott.bradley.wilson@gmail.com>
- Cc: public-webapps@w3.org
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