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

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.

/ Jonas

Received on Tuesday, 8 September 2009 01:35:55 UTC