[whatwg] HTML Cookie API

[Jeremy Orlow]

On Wed, Feb 24, 2010 at 8:23 PM, Peter Kasting <pkasting at google.com> wrote:

> On Wed, Feb 24, 2010 at 11:11 AM, Nicholas Zakas <nzakas at yahoo-inc.com>wrote:
>
>> I'm also less-than-thrilled with this being asynchronous, as I think the
>> use cases for cookies are vastly differently than those for databases and
>> web storage. The world is already parsing cookies synchronously right now,
>> it doesn't seem like asynchronicity buys much benefit, it just introduces an
>> additional level of indirection.
>
>
> You haven't just spent several tortuous weeks trying to figure out how on
> earth to correctly prompt for cookies in a multiprocess browser in a way
> that doesn't break synchronicity requirements the way we have.
>
> Synchronous access to state didn't cause many issues when browsers were all
> single-process, single-thread.  That is increasingly not going to be the
> world we live in.  As Jonas mentioned, just look at localStorage (which,
> contra your position, many developers have proposed using very much like
> cookies) for recent history of why synchronous APIs are troublesome.
>

Also note that the spec currently has the notion of a storage mutex which
should be taken whenever a script tries to access a cookie (or local
storage) and is held until the script finishes.  The network stack is also
supposed to take this lock whenever getting or setting a cookie.  No one has
implemented the storage mutex or stated any intention of doing so because
this is basically impossible today.  But, if there were an asynchronous API
that most people were using, it actually could be possible that we'd want
to implement such a mutex since cookies would then obey run to completion
semantics without having serious lock contention.


But yeah.  Definitely any API that touches information spanning tabs (and
probably even APIs spanning origins within those tabs) really should be
designed in an async manor from now on.  Otherwise we're just digging the
whole deeper in terms of forcing ourselves into a single threaded world.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100224/44876cd0/attachment-0002.htm>