- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 08 Sep 2009 17:54:12 -0700
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. Regards, Maciej
Received on Tuesday, 8 September 2009 17:54:12 UTC