I'm happy to see this getting sorted out. I like maciej's idea too.<div><div>- <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Keep the current LocalStorage API, but make it give no concurrency guarantees whatsoever. (IE's impl i think)</span></div>
<div><span class="Apple-style-span" style="font-size: 13px; "></span><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">- <span class="Apple-style-span" style="font-size: 13px; ">Add a simple optional transactional model for aware authors who want better consistency guarantees.</span></span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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) <span class="Apple-style-span" style="border-collapse: separate; font-family: verdana, helvetica, arial, sans-serif; font-size: 11px; ">onbeforeunload <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: small; border-collapse: collapse; ">will be satisfied prior to onunload.</span></span></span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><br><div class="gmail_quote">On Tue, Sep 8, 2009 at 6:21 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</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 Wed, Sep 9, 2009 at 9:54 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div></div><div><br>
On Sep 8, 2009, at 4:10 PM, Jonas Sicking wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Sep 8, 2009 at 4:00 PM, Maciej Stachowiak<<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sep 8, 2009, at 1:35 AM, Jonas Sicking wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think Firefox would be willing to break compat. The question is if<br>
microsoft is. Which we need to ask them.<br>
</blockquote>
<br>
We would be very hesitant to break LocalStorage API compatibility for<br>
Safari, at least without some demonstration that the level of  real-world<br>
breakage is low (including for mobile-specific/iPhone-specific sites).<br>
</blockquote>
<br>
Even if that means that you'll for all future will need to use a<br>
per-domain mutex protecting localStorage? And even possibly a global<br>
mutex as currently specified?<br>
</blockquote>
<br></div></div>
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.<br>
<br>
I think there are ways to solve the problem without completely breaking compatibility. For example:<br>
<br>
- Keep the current LocalStorage API, but make it give no concurrency guarantees whatsoever (only single key/value accesses are guaranteed atomic).<br>
- Add a simple optional transactional model for aware authors who want better consistency guarantees.<br>
<br>
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.<br>
<br>
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.<br>


</blockquote><div><br></div></div></div><div>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).</div>


</div>
</blockquote></div><br></div></div>