[whatwg] HTML Cookie API

[Nicholas Zakas]

I think there's always going to be a disconnect between browser
developers and web developers, since we're both living in very different
worlds.

 

Like I said, I'm all for making cookie access more rational (as if one
could argue that it has been at all rational to this point). Right now,
though, I can't see a benefit to switching from any of the current
synchronous approaches to an asynchronous one, as it doesn't give me
enough added benefit. The asynchronous approach may be the most
performant and potentially the easiest to implement, but if it's out
there and everyone is still using document.cookie, is there really a net
gain?

 

-Nicholas

 

______________________________________________

Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."

________________________________

From: jorlow at google.com [mailto:jorlow at google.com] On Behalf Of Jeremy
Orlow
Sent: Wednesday, February 24, 2010 12:20 PM
To: David Flanagan
Cc: Peter Kasting; whatwg; Nicholas Zakas; Darin Fisher; Adam Barth
Subject: Re: [whatwg] HTML Cookie API

 

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/cc227279/attachment-0002.htm>