In our case wiring Widget.preferences to window.localstorage simply won't work - we have to track state server-side and not only rely on the browser (remember we also have to handle shared-state widgets, a la Google Wave Gadgets - not just single-user, single-device-owner scenarios). However in a lot of cases it would be sufficient, so is an implementation strategy worth supporting (hence making the API conform to Storage).
S On 8 Jun 2009, at 19:34, Marcos Caceres wrote:
2009/4/25 Scott Wilson <[email protected]>:I think perhaps the underlying assumptions may vary according to the type of UA?However, I think even on a single-user O/S (e.g. mobile) or in a sandboxed user context you would still want to maintain storage of preferences on a per-instance basis.I agree. I think the common use case will be to have per instance storage.A question that arises is: what happens if the window object already provides storage? Should I use the widget storage or the window's storage. I personally think that they should be the same object (i.e., widget.preference just references whatever the Window storage object is... I don't have the spec Web Storage spec handy, so I can't remember what it is called (window.storage?)). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
smime.p7s
Description: S/MIME cryptographic signature
