- From: Michael Nordman <michaeln@google.com>
- Date: Tue, 8 Sep 2009 18:50:26 -0700
I'm happy to see this getting sorted out. I like maciej's idea too.- Keep the current LocalStorage API, but make it give no concurrency guarantees whatsoever. (IE's impl i think) - Add a simple optional transactional model for aware authors who want better consistency guarantees. There is one use-case to keep in mind... setting key/values onunload... how can we provide transactional access at that time? Maybe we could guarantee that transact calls made in (and perhaps prior to) onbeforeunload will be satisfied prior to onunload. On Tue, Sep 8, 2009 at 6:21 PM, Jeremy Orlow <jorlow at chromium.org> wrote: > On Wed, Sep 9, 2009 at 9:54 AM, Maciej Stachowiak <mjs at apple.com> wrote: > >> >> On Sep 8, 2009, at 4:10 PM, Jonas Sicking wrote: >> >> On Tue, Sep 8, 2009 at 4:00 PM, Maciej Stachowiak<mjs at apple.com> wrote: >>> >>>> >>>> On Sep 8, 2009, at 1:35 AM, Jonas Sicking wrote: >>>> >>>> >>>>> I think Firefox would be willing to break compat. The question is if >>>>> microsoft is. Which we need to ask them. >>>>> >>>> >>>> We would be very hesitant to break LocalStorage API compatibility for >>>> Safari, at least without some demonstration that the level of >>>> real-world >>>> breakage is low (including for mobile-specific/iPhone-specific sites). >>>> >>> >>> Even if that means that you'll for all future will need to use a >>> per-domain mutex protecting localStorage? And even possibly a global >>> mutex as currently specified? >>> >> >> I don't think telling this story to users or developers will make them >> satisfied with the breakage, so the "even if" is not very relevant. >> >> I think there are ways to solve the problem without completely breaking >> compatibility. For example: >> >> - Keep the current LocalStorage API, but make it give no concurrency >> guarantees whatsoever (only single key/value accesses are guaranteed >> atomic). >> - Add a simple optional transactional model for aware authors who want >> better consistency guarantees. >> >> This might not meaningfully break existing content, unlike proposals for >> effectively mandatory new API calls. Particularly since IE doesn't have any >> kind of storage mutex. >> >> Yet another possibility is to keep a per-domain mutex, also offer a >> transactional API, and accept that careless authors may indefinitely lock up >> the UI for all pages in their domain (up to the slow script execution limit) >> if they code poorly, but in exchange won't have unexpected race conditions >> with themselves. >> > > I'll see if I can't get any numbers on how widely used localStorage is > today. Assuming that we can't break compat (which I think is a strong > possibility) I think Maciej's idea is the best one so far. That said, I > think Chris's |window.localStorage == undefined| could work. Both would be > confusing to web developers in different ways, but I don't think that's > avoidable (unless we break compat). > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090908/5ab0a257/attachment.htm>
Received on Tuesday, 8 September 2009 18:50:26 UTC