On Thu, Mar 11, 2010 at 10:12 AM, Mikko Rantalainen < [email protected]> wrote:
> timeless wrote: > > On Tue, Mar 2, 2010 at 12:50 AM, ben turner <[email protected]> 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.
