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

[Jeremy Orlow]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090908/9eb43783/attachment-0002.htm>