<div class="gmail_quote">On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@google.com" target="_blank">jorlow@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">People are now talking about specifying this, but there's been push back. Also, there's no way to guarantee serializability for the network traffic portion so I'm guessing (hoping!) that this wouldn't be required in the JavaScript side, even if it went through.</blockquote>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>What exactly do you mean by that? It's easy to guarantee that reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation.</div>
</div></blockquote><div><br></div><div>True serializability would imply that the HTTP request read and write are atomic. In other words, you'd have to keep a lock for the entirety of each HTTP request and couldn't do multiple in parallel. When I said there's no way to guarantee serializability, I guess I meant to qualify it with "in practice".</div>
<div><br></div><div>After thinking about it for a bit, your suggestion of "reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation" does seems like a pretty sensible compromise.</div>
<div><br></div><div>The one thing I'd still be concerned about: localStorage separates storage space by origins. In other words, <a href="http://www.google.com">www.google.com</a> cannot access localStorage values from <a href="http://google.com">google.com</a> and visa versa. Cookies, on the other hand, have a much more complex scheme of access control. Coming up with an efficient and dead-lock-proof locking scheme might take some careful thought.</div>
<div> </div><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"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
The spec is written in such a way that you can't have more that one event loop per browser window/worker, and everything is essentially tied to this one event loop. In other words, each window/worker can't run on more than one CPU core at a time. Thus, the only way for a web application to scale in todays world is going to be through additional windows and/or workers.<br>
</blockquote></div></div><br>Depending on exactly what you mean by a "Web application", that's not really true. There are a variety of ways to exploit multicore parallelism within a window with the current set of specs, at least in principle.</blockquote>
<div><br></div><div>What else is there? (I believe you, I'm just interested in knowing what's out there.)</div><div><br></div><div>Jeremy</div><div><br></div><div>P.S. Please don't mistake me for an expert on document.cookie or even window.localStorage. I try to fact check myself as I go, but if I say something that seems stupid, please do let me know. :-)</div>
</div>