On Wed, Feb 24, 2010 at 8:52 PM, David Flanagan <span dir="ltr"><<a href="mailto:david@davidflanagan.com">david@davidflanagan.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Boris Zbarsky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2/24/10 1:04 PM, David Flanagan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If I've been following the thread correctly, the justification for an<br>
asynchronous API was that localStorage is a mess, or something like<br>
that. I'm not aware of what the issues are with localStorage<br>
</blockquote>
<br>
In brief, the fact that if you have multiple threads or processes rendering web pages from the same site, then they can race each other.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
could you justify an asynchronous cookie API more explicitly? This isn't a<br>
blocking I/O issue, is it? Surely browsers will have the relevant<br>
cookies already cached in memory, won't they?<br>
</blockquote>
<br>
Yes, but cookies are not immutable.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In simple use cases, a developer just wants the cookie value<br>
</blockquote>
<br>
Only once?  With a sync API this code:<br>
<br>
  if (document.cookie == document.cookie) {<br>
    alert("pass");<br>
  } else {<br>
    alert("fail");<br>
  }<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
will sometimes alert "fail" depending on what other web pages are loading at the same time and what their HTTP headers look like and what their scripts are doing.<br>
<br>
-Boris<br>
<br>
</blockquote>
<br>
[Changing the subject line back]<br>
<br>
Doesn't the HTML5 storage mutex fix this?<br></blockquote><div><br></div><div>Please read my email from 30 minutes ago.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


With the storage mutex mechanism it is possible to create a safe (no way to observe volatility) synchronous version of getCookies(), isn't it?</blockquote><div> </div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

The downside is that getCookies() might have to block while waiting for the mutex.</blockquote><div><br></div><div>Exactly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

But is that really a reason not to allow synchronous (blocking) access to cookies?</blockquote><div><br></div><div>YES!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Given that the storage mutex is already in the spec,</blockquote><div><br></div><div>It's in the spec, but no one has implemented it or signaled any intention to do so.  We at Google have gone so far as to say that we will not implement it.  So, even though it's there, I'm not sure how much it means at this point.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">doesn't it make sense to define a better synchronous API in addition to the new asynchronous API?</blockquote>

<div><br></div><div>Please see all the LocalStorage discussions and then see if you still think it's possible to do such a thing.</div><div><br></div><div>J</div></div>