[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

On Tue, Sep 8, 2009 at 5:35 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Tue, Sep 8, 2009 at 1:25 AM, Jeremy Orlow<jorlow at chromium.org> wrote:
> >
> >
> > On Tue, Sep 8, 2009 at 5:20 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodman<aa at google.com> wrote:
> >> > On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sicking<jonas at sicking.cc>
> wrote:
> >> >> On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodman<aa at google.com> wrote:
> >> >>> On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sicking<jonas at sicking.cc>
> >> >>> wrote:
> >> >>>> On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodman<aa at google.com>
> wrote:
> >> >>>>> On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones<cjones at mozilla.com>
> >> >>>>> wrote:
> >> >>>>>> I propose adding the functions
> >> >>>>>>
> >> >>>>>>  window.localStorage.beginTransaction()
> >> >>>>>>  window.localStorage.commitTransaction()
> >> >>>>>> or
> >> >>>>>>  window.beginTransaction()
> >> >>>>>>  window.commitTransaction()
> >> >>>>>
> >> >>>>> I think this is a good idea! I would modify it to follow the
> pattern
> >> >>>>> set by the current SQLDatabase proposal, to have a callback, like
> >> >>>>> this:
> >> >>>>>
> >> >>>>> window.localStorage.transaction(function() {
> >> >>>>>  // use local storage here
> >> >>>>> });
> >> >>>>
> >> >>>> We have discussed similar APIs in the past. Something like a:
> >> >>>>
> >> >>>> window.getLocalStorage(function (storage) {
> >> >>>>  ...use storage...
> >> >>>> });
> >> >>>>
> >> >>>> This is nice because it can be expanded to something like:
> >> >>>> window.getSharedItems(window.SHARED_ITEM_LOCALSTORAGE |
> >> >>>> window.SHARED_ITEM_COOKIES, function (...) { ... });
> >> >>>>
> >> >>>> to let you access both cookies and localStorage safely at the same
> >> >>>> time.
> >> >>>
> >> >>> I think worrying about safely accessing cookies is a bit of
> >> >>> over-design. As has been pointed out, cookies don't work correctly
> >> >>> today and the wheels haven't fallen off yet.
> >> >>>
> >> >>> I think a solution for localStorage that doesn't fix cookies is
> fine.
> >> >>>
> >> >>>> However, this requires breaking compatibility with existing syntax,
> >> >>>> something that seems impossible at this point given that Microsoft
> >> >>>> has
> >> >>>> shipped localStorage. I know Hixie has asked them in the past about
> >> >>>> how they plan to deal with the mutex problem, but I'm not sure if
> an
> >> >>>> answer has been received as of yet.
> >> >>>
> >> >>> I addressed this at the end of my last message. Specifically, I
> >> >>> suggest:
> >> >>>
> >> >>> interface LocalStorageTransactionCallback {
> >> >>>  void handleEvent();  // note: no arguments!
> >> >>> };
> >> >>>
> >> >>> interface LocalStorage {
> >> >>>  ...
> >> >>>  // LocalStorage can only be accessed inside this callback. Access
> >> >>> outside
> >> >>>  // of it will raise an exception, except in some browsers that
> >> >>> support such
> >> >>>  // behavior for legacy reasons.
> >> >>>  void transaction(LocalStorageTransactionCallback callback);
> >> >>>  ...
> >> >>> };
> >> >>>
> >> >>> With this, there is no need to change anything about the current
> API.
> >> >>> The only change is the addition of the new transaction() method.
> >> >>
> >> >> While this keeps existing IDL intact, it still breaks any existing
> >> >> pages, which is the real concern for any browser vendor I would
> think.
> >> >
> >> > Not necessarily.
> >> >
> >> > The second half of my proposal is that vendors who currently implement
> >> > local storage can choose to continue to allow access to it outside of
> >> > the transaction() callback. It seems like this would work fine for
> >> > single-event-loop browsers, right?
> >>
> >> But that results in code that works in one browser, but not another,
> >> defeating the whole point of having a standard.
> >>
> >> Would you be fine with having pages that work fine in Firefox and IE,
> >> break in Chrome?
> >
> > Well, pages that work fine in Firefox/Safari currently can break in IE
> > because IE is multi-process but does not implement a storage
> mutex...right?
>
> Yes, with a very small likelyhood. This proposal would make that
> happen every time.
>
> Again, the question needs to be posed to microsoft. I can't speak for them.
>

Understood.

If Microsoft is not willing to break compat and they're not going to
implement the storage mutex for LocalStorage, then what do we do?  Change
the spec so that there's no run to completion guarantees for LocalStorage or
leave them in the dust?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090908/539d7ef0/attachment.htm>

Received on Tuesday, 8 September 2009 01:41:28 UTC