- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 24 Feb 2010 21:06:57 +0100
On Wed, Feb 24, 2010 at 8:52 PM, David Flanagan <david at davidflanagan.com>wrote: > Boris Zbarsky wrote: > >> On 2/24/10 1:04 PM, David Flanagan wrote: >> >>> If I've been following the thread correctly, the justification for an >>> asynchronous API was that localStorage is a mess, or something like >>> that. I'm not aware of what the issues are with localStorage >>> >> >> 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. >> >> could you justify an asynchronous cookie API more explicitly? This isn't >>> a >>> blocking I/O issue, is it? Surely browsers will have the relevant >>> cookies already cached in memory, won't they? >>> >> >> Yes, but cookies are not immutable. >> >> In simple use cases, a developer just wants the cookie value >>> >> >> Only once? With a sync API this code: >> >> if (document.cookie == document.cookie) { >> alert("pass"); >> } else { >> alert("fail"); >> } >> > > 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. >> >> -Boris >> >> > [Changing the subject line back] > > Doesn't the HTML5 storage mutex fix this? > Please read my email from 30 minutes ago. > With the storage mutex mechanism it is possible to create a safe (no way to > observe volatility) synchronous version of getCookies(), isn't it? Sure. > The downside is that getCookies() might have to block while waiting for the > mutex. Exactly. > But is that really a reason not to allow synchronous (blocking) access to > cookies? YES! > Given that the storage mutex is already in the spec, 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. > doesn't it make sense to define a better synchronous API in addition to the > new asynchronous API? Please see all the LocalStorage discussions and then see if you still think it's possible to do such a thing. J -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100224/6d8123e3/attachment.htm>
Received on Wednesday, 24 February 2010 12:06:57 UTC