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

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?

/ Jonas

Received on Tuesday, 8 September 2009 01:20:13 UTC