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

Aaron Boodman aa at google.com
Tue Sep 8 01:18:11 PDT 2009


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?

- a



More information about the whatwg mailing list