On Tue, Sep 8, 2009 at 1:25 AM, Jeremy Orlow<jor...@chromium.org> wrote: > > > On Tue, Sep 8, 2009 at 5:20 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Tue, Sep 8, 2009 at 1:18 AM, Aaron Boodman<a...@google.com> wrote: >> > On Tue, Sep 8, 2009 at 1:13 AM, Jonas Sicking<jo...@sicking.cc> wrote: >> >> On Tue, Sep 8, 2009 at 1:07 AM, Aaron Boodman<a...@google.com> wrote: >> >>> On Tue, Sep 8, 2009 at 12:54 AM, Jonas Sicking<jo...@sicking.cc> >> >>> wrote: >> >>>> On Tue, Sep 8, 2009 at 12:00 AM, Aaron Boodman<a...@google.com> wrote: >> >>>>> On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones<cjo...@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