[whatwg] whatwg Digest, Vol 71, Issue 72

[David Flanagan]

Adam Barth wrote:
   We don't want
> to use the array syntax because we want the API to be asynchronous.
> 
> Adam

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: 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?

In simple use cases, a developer just wants the cookie value, and having 
to break an algorithm up into two functions because of an asynchronous 
API is a burden. There are lots of ways to wrap easy-to-use synchronous 
APIs around document.cookie. Do you think that developers will really 
transition to a slightly inconvenient async API when they could grab an 
off-the-shelf cookie library with an easier to use synchronous API?

I guess I'm asking whether there is some fundamental reason why 
developers should be encouraged to abandon synchronous cookies.  And if 
not, can we provide a nice synchronous API at the same time as a nice 
async API?   How about getCookies() is synchronous when called with no 
arguments, but is async when passed a callback?

	David