[whatwg] HTML Cookie API

[David Flanagan]

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