[whatwg] Accessing cookies from workers

On Mon, Mar 9, 2009 at 11:01 AM, Giovanni Campagna
<scampa.giovanni at gmail.com> wrote:
> 2009/3/9 Jonas Sicking <jonas at sicking.cc>:
>> On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson <atwilson at google.com> wrote:
>>>
>>> On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>>
>>>> However a much more interesting question is if sites would break if
>>>> the above stopped being true. That is most definitely the case.
>>>
>>> Agreed - existing behavior trumps spec ambiguity. However, in this case I
>>> was assuming that breaking existing sites was not an issue since we're
>>> adding completely new functionality (accessing cookies from workers).
>>> Existing sites won't break unless they add worker code that modifies
>>> cookies, although perhaps that's a situation we need to avoid as well.
>>
>> I wouldn't expect new sites to be able to cope with this either. Even
>> if we put in the spec that the value can change at any time, it is
>> extremely unlikely that developers will deal with this appropriately.
>
> They cannot deal with that, given they don't have any syncronization
> mechanism outside the event system. To control the value of shared
> variables, you need a lock on that variable while you're using it.

Indeed, in a multithread environment we'd need that. However the goal
of workers is to use a shared-nothing message passing model where this
is not needed. Think of them as separate processes rather than
separate threads.

>> See my analogy earlier in this thread regarding how hard it is to
>> write multi-threaded code, even for expert C++ developers. It is
>> definitely not something I would expect copy-n-paste web developers to
>> get right.
>
> If you don't understand the logics of multithreading, you should not
> use workers (that are just ecmascript threads with a message queue),
> IMHO.

Why? In the drafts that exist today (with the exception of
localStorage), why is this needed?

>>>> This is a very interesting suggestion. If we add a cookie access API
>>>> then this would seem like a reasonable thing to require from that API.
>>>>
>>>
>>> OK, to summarize, the suggestion is that we add something like the following
>>> to WorkerGlobalScope:
>>>
>>> String getAllCookies() - analogous to document.cookies in the DOM world
>>
>> 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.
>
> This can be even worse: how would you syncronize the code in the
> callback with code right after the call? You don't have any of
> semaphores or mutexes in ES and I don't expect them to be added soon.

I'm not sure I understand the problem you are describing. Could you
show an example using the APIs that exist in the spec today and with
an async cookie API added?

/ Jonas

Received on Monday, 9 March 2009 11:10:32 UTC