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
