[whatwg] Accessing cookies from workers
jonas at sicking.cc
Mon Mar 9 11:10:32 PDT 2009
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
>> 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),
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?
More information about the whatwg