- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 9 Mar 2009 10:42:42 -0700
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. 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. >> 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. / Jonas
Received on Monday, 9 March 2009 10:42:42 UTC