On Wed, Feb 24, 2010 at 8:23 PM, Peter Kasting <span dir="ltr"><<a href="mailto:pkasting@google.com">pkasting@google.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;">
<div class="gmail_quote"><div class="im">On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas <span dir="ltr"><<a href="mailto:nzakas@yahoo-inc.com" target="_blank">nzakas@yahoo-inc.com</a>></span> wrote:<br></div><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm also less-than-thrilled with this being asynchronous, as I think the use cases for cookies are vastly differently than those for databases and web storage. The world is already parsing cookies synchronously right now, it doesn't seem like asynchronicity buys much benefit, it just introduces an additional level of indirection.</blockquote>
<div><br></div></div><div>You haven't just spent several tortuous weeks trying to figure out how on earth to correctly prompt for cookies in a multiprocess browser in a way that doesn't break synchronicity requirements the way we have.</div>
<div><br></div><div>Synchronous access to state didn't cause many issues when browsers were all single-process, single-thread. That is increasingly not going to be the world we live in. As Jonas mentioned, just look at localStorage (which, contra your position, many developers have proposed using very much like cookies) for recent history of why synchronous APIs are troublesome.</div>
</div></blockquote><div><br></div><div>Also note that the spec currently has the notion of a storage mutex which should be taken whenever a script tries to access a cookie (or local storage) and is held until the script finishes. The network stack is also supposed to take this lock whenever getting or setting a cookie. No one has implemented the storage mutex or stated any intention of doing so because this is basically impossible today. But, if there were an asynchronous API that most people were using, it actually could be possible that we'd want to implement such a mutex since cookies would then obey run to completion semantics without having serious lock contention.</div>
<div><br></div><div><br></div><div>But yeah. Definitely any API that touches information spanning tabs (and probably even APIs spanning origins within those tabs) really should be designed in an async manor from now on. Otherwise we're just digging the whole deeper in terms of forcing ourselves into a single threaded world.</div>
<div><br></div><div>J</div></div>