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?
With the storage mutex mechanism it is possible to create a safe (no way
to observe volatility) synchronous version of getCookies(), isn't it?
The downside is that getCookies() might have to block while waiting for
the mutex. But is that really a reason not to allow synchronous
(blocking) access to cookies? Given that the storage mutex is already
in the spec, doesn't it make sense to define a better synchronous API in
addition to the new asynchronous API?
David
