Re: [whatwg] Web Workers and postMessage(): Questions
On Mon, 3 Aug 2009, Daniel Gredler wrote: > On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: > > On Wed, 22 Jul 2009, Daniel Gredler wrote: > > > Second, why not walk the prototype chain? Similar rules regarding > > > host objects and regular objects could apply to prototypes. You > > > would want to make sure that multiple references to the same > > > prototype instance result in references to a single prototype clone > > > in the cloned object graph. Again, though, it doesn't sound too hard > > > (though I might just be optimistic). Why not make web designers' > > > lives easier? > > > > We're definitely never going to copy function code over, so it's not > > clear that the prototype chain would be that useful. Could you > > elaborate on your use case? > > I agree that once you've made the decision to not clone functions, > cloning the prototype chain becomes (nearly?) useless. However, I'd be > interested to know the rationale behind this decision, since Web Workers > appear to follow the same-origin policy (e.g. "If the origin of the > resulting absolute URL is not the same as the origin of the script that > invoked the constructor, then throw a security exception", etc). I > assume there's a security concern lurking somewhere? Workers obey the same-origin policy for creation, but you can easily pass ports around so that non-same-origin code can talk to your worker. > My specific use case spits out a tree, each node having a reference to > its children and its parent (hence the issue with circular references). > Each node also has a "name" attribute and a function (in the prototype) > used to retrieve the node's "path" (based on its name and its ancestors > names) -- I don't want to precalculate each node's path and keep it in > memory, given that there are tens of thousands of nodes (or more). Serialise the tree and pass the serialised version, then reconstruct the objects on the other side. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Workers and postMessage(): Questions
On Mon, Aug 3, 2009 at 4:14 PM, Robert O'Callahan wrote: > On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler > wrote: >> >> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any >> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out >> there with comments? > > I know very little about these issues. Jonas Sicking reads this list and > would know more. While I think dealing with cycles could be done, I agree with others that there are things of higher priority, like supporting ImageData or Files. What are the use cases for cyclic data? I'll note that neither JSON nor XML, which are also data-container formats, opted to allow for cycles. / Jonas
Re: [whatwg] Web Workers and postMessage(): Questions
On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler wrote: > I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any > comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out > there with comments? I know very little about these issues. Jonas Sicking reads this list and would know more. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Web Workers and postMessage(): Questions
On Mon, 03 Aug 2009 19:47:14 +0200, Maciej Stachowiak wrote: > I'd prefer to stick with JSONic object graphs for now. Correctly > cloning more complicated object structures is a fair bit more > complicated, so I'd like to get solid interop on the basic cases > first. Also, the idea is that postMessage() should be sending object > structures that are essentially pure data. JSON seems to capture > pretty well the idea of a pure data structure in JavaScript. Well, it doesn't cover e.g. ImageData, which postMessage() allows for, and which seems useful to have. (No informed opinion on allowing cycles.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Web Workers and postMessage(): Questions
On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler wrote:
>
>> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
> there with comments?
>
I've often had the same thought (that there's no reason we shouldn't handle
cycles when implementing structured clones).
That said, I'm compelled to point out that WebKit browsers only support
string messages currently (they don't yet implement the structured clone
part of the spec). And none of the currently shipping browsers support
MessagePorts or SharedWorkers (although WebKit browsers are getting these
soon). So given that there's a workaround for the lack of support for cycles
in structured clones (applications can do their own serialization) but
there's no app-level workaround for the lack of SharedWorkers, I'd rather
see vendors concentrate on implementing the current spec before adding
greater support for cloning message parameters.
>
> I agree that once you've made the decision to not clone functions, cloning
> the prototype chain becomes (nearly?) useless. However, I'd be interested to
> know the rationale behind this decision, since Web Workers appear to follow
> the same-origin policy (e.g. "If the origin of the resulting absolute URL is
> not the same as the origin of the script that invoked the constructor, then
> throw a security exception", etc). I assume there's a security concern
> lurking somewhere?
>
It's not clear to me how you'd clone the lexical scope of a function and
carry it over to the worker in a way that doesn't cause synchronization
issues.
Case in point:
var obj = {};
var foo = "abc";
obj.bar = function() { foo = "def"; }
sharedWorker.port.postMessage(obj);
Now, from shared worker scope, you have the ability to directly access the
variable "foo" from a different thread/process, which is not really
implementable.
-atw
Re: [whatwg] Web Workers and postMessage(): Questions
On Aug 3, 2009, at 10:34 AM, Daniel Gredler wrote: On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: On Wed, 22 Jul 2009, Daniel Gredler wrote: > > First, why does the structured clone algorithm used by postMessage() [1] > throw an exception if it encounters cycles? It seems to me that the > memory-based logic which is used to catch cycles could easily be > modified to resolve them instead. The only possible reason I can think > of is to match JSON semantics, and the only reason I can think of to > want to match JSON semantics is to make implementers lives easier > (witness Firefox 3.5, which just JSONifies objects passed to > postMessage()). However, this is a huge limitation, and I'm not sure > that the correct trade-off is to make implementers lives easier at the > expense of making web designers lives harder. Your guess is correct. I imagine we'll lift the restriction eventually; if you want to make that happen quicker, then I encourage you to speak directly to the browser vendors implementing this, and convince them it'd be worth it. :-) I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out there with comments? I'd prefer to stick with JSONic object graphs for now. Correctly cloning more complicated object structures is a fair bit more complicated, so I'd like to get solid interop on the basic cases first. Also, the idea is that postMessage() should be sending object structures that are essentially pure data. JSON seems to capture pretty well the idea of a pure data structure in JavaScript. Regards, Maciej
Re: [whatwg] Web Workers and postMessage(): Questions
On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson wrote: > On Wed, 22 Jul 2009, Daniel Gredler wrote: > > > > First, why does the structured clone algorithm used by postMessage() [1] > > throw an exception if it encounters cycles? It seems to me that the > > memory-based logic which is used to catch cycles could easily be > > modified to resolve them instead. The only possible reason I can think > > of is to match JSON semantics, and the only reason I can think of to > > want to match JSON semantics is to make implementers lives easier > > (witness Firefox 3.5, which just JSONifies objects passed to > > postMessage()). However, this is a huge limitation, and I'm not sure > > that the correct trade-off is to make implementers lives easier at the > > expense of making web designers lives harder. > > Your guess is correct. I imagine we'll lift the restriction eventually; if > you want to make that happen quicker, then I encourage you to speak > directly to the browser vendors implementing this, and convince them it'd > be worth it. :-) > I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out there with comments? > > Second, why not walk the prototype chain? Similar rules regarding host > > objects and regular objects could apply to prototypes. You would want to > > make sure that multiple references to the same prototype instance result > > in references to a single prototype clone in the cloned object graph. > > Again, though, it doesn't sound too hard (though I might just be > > optimistic). Why not make web designers' lives easier? > > We're definitely never going to copy function code over, so it's not clear > that the prototype chain would be that useful. Could you elaborate on your > use case? > I agree that once you've made the decision to not clone functions, cloning the prototype chain becomes (nearly?) useless. However, I'd be interested to know the rationale behind this decision, since Web Workers appear to follow the same-origin policy (e.g. "If the origin of the resulting absolute URL is not the same as the origin of the script that invoked the constructor, then throw a security exception", etc). I assume there's a security concern lurking somewhere? My specific use case spits out a tree, each node having a reference to its children and its parent (hence the issue with circular references). Each node also has a "name" attribute and a function (in the prototype) used to retrieve the node's "path" (based on its name and its ancestors names) -- I don't want to precalculate each node's path and keep it in memory, given that there are tens of thousands of nodes (or more). > Overall, it just appears that the current web worker spec ignores the > > class of computational problems involving results which need to be > > modeled in a complex way. > > That's probably a fair criticism, yes. > Then I'll see if I can't raise some awareness amongst implementers ;-) -- Daniel Gredler http://daniel.gredler.net/
Re: [whatwg] Web Workers and postMessage(): Questions
On Wed, 22 Jul 2009, Daniel Gredler wrote: > > First, why does the structured clone algorithm used by postMessage() [1] > throw an exception if it encounters cycles? It seems to me that the > memory-based logic which is used to catch cycles could easily be > modified to resolve them instead. The only possible reason I can think > of is to match JSON semantics, and the only reason I can think of to > want to match JSON semantics is to make implementers lives easier > (witness Firefox 3.5, which just JSONifies objects passed to > postMessage()). However, this is a huge limitation, and I'm not sure > that the correct trade-off is to make implementers lives easier at the > expense of making web designers lives harder. Your guess is correct. I imagine we'll lift the restriction eventually; if you want to make that happen quicker, then I encourage you to speak directly to the browser vendors implementing this, and convince them it'd be worth it. :-) > Second, why not walk the prototype chain? Similar rules regarding host > objects and regular objects could apply to prototypes. You would want to > make sure that multiple references to the same prototype instance result > in references to a single prototype clone in the cloned object graph. > Again, though, it doesn't sound too hard (though I might just be > optimistic). Why not make web designers' lives easier? We're definitely never going to copy function code over, so it's not clear that the prototype chain would be that useful. Could you elaborate on your use case? > Overall, it just appears that the current web worker spec ignores the > class of computational problems involving results which need to be > modeled in a complex way. That's probably a fair criticism, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Web Workers and postMessage(): Questions
Hi all, I've been writing some code that uses web workers. It's a very nice addition to the HTML toolbox (kudos!), but I have some questions: First, why does the structured clone algorithm used by postMessage() [1] throw an exception if it encounters cycles? It seems to me that the memory-based logic which is used to catch cycles could easily be modified to resolve them instead. The only possible reason I can think of is to match JSON semantics, and the only reason I can think of to want to match JSON semantics is to make implementers lives easier (witness Firefox 3.5, which just JSONifies objects passed to postMessage()). However, this is a huge limitation, and I'm not sure that the correct trade-off is to make implementers lives easier at the expense of making web designers lives harder. Second, why not walk the prototype chain? Similar rules regarding host objects and regular objects could apply to prototypes. You would want to make sure that multiple references to the same prototype instance result in references to a single prototype clone in the cloned object graph. Again, though, it doesn't sound too hard (though I might just be optimistic). Why not make web designers' lives easier? Overall, it just appears that the current web worker spec ignores the class of computational problems involving results which need to be modeled in a complex way. What do others think? Looking forward to feedback! Daniel [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#structured-clone -- Daniel Gredler http://daniel.gredler.net/
