[whatwg] HTML Cookie API

[Jeremy Orlow]

On Wed, Feb 24, 2010 at 9:07 PM, David Flanagan <david at davidflanagan.com>wrote:

> Jeremy Orlow wrote:
>
>
>> 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.
>>
>>
> Well if no one is going to implement the storage mutex, then I probably
> need to retract my last message
>
>
>  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
>>
>
> I worry that this comes down to web developers who want simple APIs vs
> browser implementors who say we can't have them (at least not if we also
> want speed.)
>
> Concurrency issues are not my strong suit, but shouldn't it be possible to
> have safe, synchronous read-only access to cookies (caching volatile values
> like cookies within each thread and then clearing that cache when the thread
> returns to the event loop).  Can't the requirement for a mutex or an
> asynchronous API be limited to setCookie()?
>

>From a technical standpoint, this is very doable.  And, done right, I think
I could be in favor of it.

But I believe the counter argument is that any relaxation of run
to completion semantics is going to confuse developers and probably result
in them writing racy code without realizing it.  Many developers won't
understand when it's safe to use the cached value vs needing to use the
asynchronous interface.  And if the less safe one is easier to use....

I agree that asynchronous interfaces have disadvantages, but as far as I can
tell many of them are costs that you pay once (learning them and getting use
to them) or once per app (if you handle one asynchronous call or need to use
setTimeout, then probably using another won't require too much restructuring
of your code).  Maybe I'm just a browser developer who's completely out of
touch with reality though.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100224/ef58d2f4/attachment.htm>