<div class="gmail_quote">On Tue, Sep 8, 2009 at 5:33 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, Sep 8, 2009 at 1:20 AM, Jonas Sicking<jonas@sicking.cc> wrote:<br>
> On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodman<<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
>> On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sicking<jonas@sicking.cc> wrote:<br>
>>> On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodman<<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
>>>> On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sicking<jonas@sicking.cc> wrote:<br>
>>>>> On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodman<<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
>>>>>> On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones<<a href="mailto:cjones@mozilla.com">cjones@mozilla.com</a>> wrote:<br>
>>>>>>> I propose adding the functions<br>
>>>>>>><br>
>>>>>>> window.localStorage.beginTransaction()<br>
>>>>>>> window.localStorage.commitTransaction()<br>
>>>>>>> or<br>
>>>>>>> window.beginTransaction()<br>
>>>>>>> window.commitTransaction()<br>
>>>>>><br>
>>>>>> I think this is a good idea! I would modify it to follow the pattern<br>
>>>>>> set by the current SQLDatabase proposal, to have a callback, like<br>
>>>>>> this:<br>
>>>>>><br>
>>>>>> window.localStorage.transaction(function() {<br>
>>>>>> // use local storage here<br>
>>>>>> });<br>
>>>>><br>
>>>>> We have discussed similar APIs in the past. Something like a:<br>
>>>>><br>
>>>>> window.getLocalStorage(function (storage) {<br>
>>>>> ...use storage...<br>
>>>>> });<br>
>>>>><br>
>>>>> This is nice because it can be expanded to something like:<br>
>>>>> window.getSharedItems(window.SHARED_ITEM_LOCALSTORAGE |<br>
>>>>> window.SHARED_ITEM_COOKIES, function (...) { ... });<br>
>>>>><br>
>>>>> to let you access both cookies and localStorage safely at the same time.<br>
>>>><br>
>>>> I think worrying about safely accessing cookies is a bit of<br>
>>>> over-design. As has been pointed out, cookies don't work correctly<br>
>>>> today and the wheels haven't fallen off yet.<br>
>>>><br>
>>>> I think a solution for localStorage that doesn't fix cookies is fine.<br>
>>>><br>
>>>>> However, this requires breaking compatibility with existing syntax,<br>
>>>>> something that seems impossible at this point given that Microsoft has<br>
>>>>> shipped localStorage. I know Hixie has asked them in the past about<br>
>>>>> how they plan to deal with the mutex problem, but I'm not sure if an<br>
>>>>> answer has been received as of yet.<br>
>>>><br>
>>>> I addressed this at the end of my last message. Specifically, I suggest:<br>
>>>><br>
>>>> interface LocalStorageTransactionCallback {<br>
>>>> void handleEvent(); // note: no arguments!<br>
>>>> };<br>
>>>><br>
>>>> interface LocalStorage {<br>
>>>> ...<br>
>>>> // LocalStorage can only be accessed inside this callback. Access outside<br>
>>>> // of it will raise an exception, except in some browsers that support such<br>
>>>> // behavior for legacy reasons.<br>
>>>> void transaction(LocalStorageTransactionCallback callback);<br>
>>>> ...<br>
>>>> };<br>
>>>><br>
>>>> With this, there is no need to change anything about the current API.<br>
>>>> The only change is the addition of the new transaction() method.<br>
>>><br>
>>> While this keeps existing IDL intact, it still breaks any existing<br>
>>> pages, which is the real concern for any browser vendor I would think.<br>
>><br>
>> Not necessarily.<br>
>><br>
>> The second half of my proposal is that vendors who currently implement<br>
>> local storage can choose to continue to allow access to it outside of<br>
>> the transaction() callback. It seems like this would work fine for<br>
>> single-event-loop browsers, right?<br>
><br>
> But that results in code that works in one browser, but not another,<br>
> defeating the whole point of having a standard.<br>
><br>
> Would you be fine with having pages that work fine in Firefox and IE,<br>
> break in Chrome?<br>
<br>
</div></div>I don't really see another option. People on the Chrome team are<br>
saying it may be impractical to implement the spec as-is. Presumably<br>
Firefox is unwillingly to break backward compatibility. If both of<br>
these are true, we are headed for a split.</blockquote><div><br></div><div>To be clear, Chrome is not going to implement the storage mutex with respect to cookies, but we are going to implement it for LocalStorage. Because of this, we can handle the localStorage mutex on a per-origin basis (which I'm implementing right now). That said, we're not happy about having a synchronous interface that connects otherwise completely independent windows.</div>
</div>