-atw
On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke wrote:
>
> 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).
>>
&g
This is one of those times when I *really* wish that the application
developer community was more active on this list. I absolutely understand
Linus' point of view, but I also feel like we are really hamstringing
applications when we make choices like this and I wish that those developers
were more
Likewise it is no longer entangled and so you can't send messages via
it. Re-sending a cloned port is an error, and we should treat it as such.
-atw
On Fri, Aug 28, 2009 at 12:11 PM, Ian Hickson wrote:
> On Mon, 17 Aug 2009, Drew Wilson wrote:
> >
> > Following up
This would be my inclination as well. I'm not entirely convinced that "every
web app should define their own idle timeout" is such desirable behavior
that we should build our API around it by forcing every caller to specify
their idle timeout - having a standard event that's fired with an exposed
s
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 pushbac
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 simultan
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg wrote:
> 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 d
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 imp
Agreed - I've always felt like having to have a reference to a window would
be an obstacle.
I feel obliged to point out that cross-domain SharedWorkers might be another
option for two completely unrelated windows to interact, although the
suggestions I've heard for APIs for x-domain access seem to
Jeremy, what's the use case here - do developers want workers to have access
to shared local storage with pages? Or do they just want workers to have
access to their own non-shared local storage?
Because we could just give workers their own separate WorkerLocalStorage and
let them have at it. A wor
t 11:24 AM, James Robinson wrote:
>
>> On Wed, Sep 16, 2009 at 10:53 AM, Michael Nordman wrote:
>>
>>>
>>>
>>> On Wed, Sep 16, 2009 at 9:58 AM, Drew Wilson wrote:
>>>
>>>> Jeremy, what's the use case here - do developers want wo
Thanks, Robert - I didn't want to second my own proposal :)
I think that #4 is probably a reasonable bridge API until we come up with a
consensus API for #3. For myself, I see this API as being very useful for
persistent workers (yes, I'm still banging that drum :).
-atw
On Wed, Sep 16, 2009 at 3
Are you saying that if I load a script via a
Certainly. If I explicitly override the charset, then that seems like
reasonable behavior.
Having the default decoding vary between importScripts() and
ig5-encoded script
(containing, say, string resources) with the appropriate charset header will
find it fails when loaded into workers.
Again, apologies if I'm misunderstanding the suggestion.
-atw
On Fri, Sep 25, 2009 at 10:21 AM, Anne van Kesteren wrote:
> On Fri, 25 Sep 200
ough - since workers don't inherit the document
encoding from their parent, they may indeed decode a given resource
differently if the server isn't specifying a charset in some way.
-atw
On Mon, Sep 28, 2009 at 4:47 AM, Anne van Kesteren wrote:
> On Fri, 25 Sep 2009 19:34:18 +0200,
The intent of the spec is fairly clear that addEventListener("message")
should not start the message queue dispatch - only setting the onmessage
attribute does that:
The first time a MessagePort <#messageport> object's
onmessage<#handler-messageport-onmessage> IDL
attribute is set, the port's port
On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson wrote:
>
>
> There's no start() to call, since there's no explicit pointer to the
> MessagePort in dedicated workers.
>
>
The example in the worker spec refers to shared workers, which *do* have an
explicit port, and do not automatically start the port
To be absolutely clear (since there's some confusion about whether we are
talking about explicit MessagePorts, or about implicit ports for dedicated
workers).
Are you saying that this:
var channel = new MessageChannel();
channel.port1.postMessage("hi mom");
channel.port2.addEventListener("message"
As a data point, the WebKit implementation (used by Safari and Chrome)
doesn't currently enforce any limits (other than those imposed by running
out of memory).
-atw
On Fri, Oct 23, 2009 at 12:02 AM, Ian Hickson wrote:
> On Thu, 22 Oct 2009, Brian Kuhn wrote:
> >
> > Is there any limit to the le
FWIW, I've usually looked at self.postMessage when trying to determine
whether running in dedicated or shared worker context, although Anne's
suggestion (using "in") is better.
-atw
On Mon, Oct 26, 2009 at 7:00 AM, Anne van Kesteren wrote:
> On Mon, 26 Oct 2009 13:57:10 +0100, Simon Pieters
>
We discussed this previously (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html) -
the consensus was that since the Worker APIs are inherently asynchronous,
user agents were free to impose limits on worker creation (and queue up new
creation requests when the limit has been
I'm not certain what a "deep copy" of the function means - would you need to
copy the entire lexical scope of the function? For example, let's say you do
this:
var foo = 1;
function setFoo(val) { foo = val; }
function getFoo() { return foo; }
worker.postMessage(setFoo);
worker.postMessage(getFoo
101 - 123 of 123 matches
Mail list logo
