I think the canonical racy case is the page wants to keep a counter for the
number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/1/09 7:31 PM, Jeremy Orlow wrote:
Does the silence mean that no one has any intention of implementing
this? If so, maybe we should resign ourselves to a break in the single
threaded illusion for cookies. This doesn't seem too outlandish
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
Is it important that continue to work without racing? I don't think it's
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's a conflict with other changes that happened in the meantime?
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg bsmedb...@mozilla.comwrote:
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/3/09 5:06 PM, Aryeh Gregor wrote:
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedbergbenja...@smedbergs.us
wrote:
* When the script sets document.cookie, it calculates the delta with the
original data and commit the changes.
What if there's
On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
What kind of conflict? There is no need to merge individual cookies:
whichever one was set (or removed) last wins.
I think this strategy would work fine for cookies since the HTTP side of
them is inherently racy. I
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
I do agree with Jeremy that we should rethink the spec language around
cookie consistency to reflect what
On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson atwil...@google.com wrote:
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
And to be clear: I don't have
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers to
use the more difficult database api for all storage needs, and to roll their
own change event mechanisms (based on postMessage). Thats a bunch of busy
work if a name/value pair
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult database api for all storage needs, and to roll
their own change event
On Fri, Sep 4, 2009 at 10:59 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman micha...@google.comwrote:
Shared worker access would be a plus.
Indeed. The lack of access to LocalStorage in 'workers' forces developers
to use the more difficult
On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow
When we had this discussion last, there was significant pushback on this -
the argument was basically we have no evidence that cookie-based race
conditions *aren't* causing sporadic breakages, which is true. It's
inherently difficult to measure.
As an aside, I'll note that the majority of pushback
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.orgwrote:
Is there any data (or any way to collect the data) on how much of
On Wed, Sep 2, 2009 at 11:31 AM, Jeremy Orlow jor...@chromium.org wrote:
Does the silence mean that no one has any intention of implementing this?
I'm silent because I'm not currently working on this stuff so I can't say
what our plans are. But I'll be upset if I find out our plans are to
I know that one of the design issues with worker threads and local
storage has been how to resolve concurrency issues, and that for this
reason, in the current spec worker threads can't access local storage.
However, there's a scenario under the current spec that doesn't
involve local
My recollection is that we prohibit worker access to cookies for exactly
this reason (WorkerGlobalScope does not expose a cookies attribute).
-atw
On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke s...@google.com wrote:
I know that one of the design issues with worker threads and local storage
has
On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote:
My recollection is that we prohibit worker access to cookies for
exactly this reason (WorkerGlobalScope does not expose a cookies
attribute).
Looks like you're right; section 5 of the Web Workers spec says:
The DOM APIs (Node objects,
We discussed this in more detail here:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html
At the time, I suggested not protecting cookies with a mutex (allow
asynchronous access - the current behavior on IE and Chrome), which made the
monocles pop out of everyone's eyes :)
-atw
Is there any data (or any way to collect the data) on how much of the web IE
and Chrome's current behavior has broken? Given that there hasn't been
panic in the streets, I'm assuming approximately 0%?
Given that web developers have never had any guarantees for cookie
access/setting in terms of
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow jor...@chromium.org wrote:
Is there any data (or any way to collect the data) on how much of the web
IE and Chrome's current behavior has broken? Given that there
22 matches
Mail list logo
