[whatwg] Web Workers feedback

[Jonas Sicking]

> On Mon, 1 Mar 2010, ben turner wrote:
>>
>> I'm implementing the structured clone algorithm and this part bothers me
>> a little bit:
>>
>>   - If input is a host object (e.g. a DOM node)
>>       Return the null value.
>>
>> Seems like this has the potential to confuse web programmers somewhat.
>> If I were to write code like this:
>>
>>   worker.postMessage(window);
>>
>> I would expect something meaningful to happen as long as no exception
>> was generated. According to the spec, though, we would send null to the
>> worker and not generate any exception. Is that really desirable?
>>
>> I like the idea of making the structured clone as friendly as possible
>> but maybe we should add some teeth to this case just like we do for
>> recursive objects?
>
> We can't send "true" DOM objects across the divide, since implementations
> don't support DOMs in their worker implementations. I'm not really sure
> what else we should do. If we do something other than send null today,
> it's going to make it very difficult to later start cloning real DOM
> objects if we ever support that.

For what it's worth, I think Ben was asking for an exception to be thrown.

> On Thu, 11 Mar 2010, Mikko Rantalainen 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.
>
> We could throw an exception, but that would make migrating from this not
> being supported to this being supported later a lot harder (you'd have to
> catch exceptions and then remove the nodes, rather than just doing null
> checks in the worker). I don't know that that's worth it.

I don't see why it would be harder to add support for passing objects
later harder. I would say quite the opposite. People are more likely
to come to depend on objects down in an object graph being converted
to null, than they are to come to depend on that throwing an
exception.

Additionally, it's unlikely that converting to null is the fallback
behavior you want for downlevel clients. Likely you'd want to manually
serialize such objects and then parse them on the receiver side. In
this case too an exception would likely help you more than silently
converting to null.

/ Jonas