- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 11 Mar 2010 11:10:46 +0000
On Thu, Mar 11, 2010 at 10:12 AM, Mikko Rantalainen < mikko.rantalainen at peda.net> wrote: > timeless wrote: > > On Tue, Mar 2, 2010 at 12:50 AM, ben turner <bent at mozilla.com> wrote: > >> - If input is a host object (e.g. a DOM node) > >> Return the null value. > > > > The general reason, I believe for this behavior is if you have: > > > > a=[x,y,z,q,r,s]; worker.postMessage(a) and r turns out to be window, > > you don't want to trigger an exception just because one value in a > > list is a native object. > > Why do you think so? I'd expect an exception instead of potential data > loss (due to not being to able to post the actual data to the worker). > I'd be happy to filter the "r" out of the list if I need to, but I'd > hate to try to figure why *some* of the data I was posting does not show > up at the worker. Obviously, if I know that I cannot post "r" and I > don't want to do the filtering myself, it would be nice to have an extra > parameter for postMessage() telling that it's okay to drop some data if > it cannot be transferred but that should not be the default. However, I > would consider that a special case and API could do just fine without > such feature. > FWIW, I'd have to agree that throwing an exception when there's something that can't be completely serialized makes sense, but I haven't been following structured clone discussions, so I don't know whether this has come up before and if there was a good reason for what's currently being done. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100311/e3dadd78/attachment.htm>
Received on Thursday, 11 March 2010 03:10:46 UTC