[whatwg] Accessing cookies from workers

[Jonas Sicking]

On Mon, Mar 9, 2009 at 11:07 AM, Drew Wilson <atwilson at google.com> wrote:
>>
>> No, this is a synchronous API which is not acceptible since it creates
>> a multithreaded environment for web developers. You need to use a
>> callback function.
>
> Hmmm, I must've misinterpreted your previous statement:
>
>>>> It seems like it should fine to allow reading cookies in dedicated
>>>> workers though.

No, you're not wrong. *I* was wrong when I wrote the above statement.

> I'm sure I'm being obtuse, but I don't understand what you are saying here.
>
> Let's imagine that I have a synchronous API - you are saying that this is
> bad, because when I do this:
>
> var cookies = self.getAllCookies();
> doSomethingWithCookies(cookies);

The problem is that people are likely to write code like:

if (self.getAllCookies() != "magic value") {
  a = self.getAllCookies();
  ...do stuff...
}

at that point it's entirely possible for 'a' to have the value "magic
value" which is likely to cause the script to break.

> So, let's assume instead that we allow passing a callback to
> getAllCookies():
>
> self.getAllCookies( function(cookies) { doSomethingWithCookies(cookies); })
>
> When doSomethingWithCookies() is invoked, whatever operation it is
> performing may fail, because the passed-in value of cookies may still be out
> of date.
>
> Making getAllCookies() asynchronous means that the trivial fail case:
>
> var a = getAllCookies();
> var b = getAllCookies();
> assert(a === b);
>
> ...can no longer fail because there's no return value. But fundamentally the
> underlying problem continues to exist - the cookies may have changed behind
> the scene, so whatever snapshot you have (either delivered synchronously or
> asynchronously) may be out-of-date. So making getAllCookies() asynchronous
> does not buy you anything, and additionally makes this API painful to use.

The only thing it prevents is for the javascript code to get inconsistent state.

I do agree that once you hit the wire using XHR or something else you
risk not having the state that you thought you would. I'm not sure
what to do about that problem.

> As an aside, I wonder how a multi-process browser like Chrome handles
> cookies even in the absence of workers - if I open two windows (separate
> processes) under the same domain and set cookies in both, it seems like
> there's an existing race condition.

Indeed. It does seem like you would be able to ask ;)

/ Jonas