[whatwg] Web Workers feedback

[Sigbjorn Finne]

On 3/30/2010 09:54, Jonas Sicking wrote:
> On Tue, Mar 30, 2010 at 12:20 AM, Ian Hickson <ian at hixie.ch> wrote:
>   
>> On Mon, 29 Mar 2010, Jonas Sicking wrote:
>>     
>> ...
>>> 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.
>>>       
>> It depends on how critical the DOM node is. If it's just a reference deep
>> inside some nested structure, which the other side only uses as an
>> additional hint rather than as a required component of the corresponding
>> algorithm, it's simpler just to have the UA convert it to null.
>>     
> Ok, I guess it comes down to if we think it's more likely that people
> will send Nodes and other unsupported objects by accident or as
> optional data, or because they really want to send them.
>
> Personally my guess it's more likely that they really wanted to.
>   

Hence tell them upfront that they are straying outside the supported set
of objects.

At Opera, we've gone back and forth on what's the preferable behaviour
here (previous spec versions did choose exceptions, I believe.) A third
option, and the traditional way of solving serialisation extensibility,
is to define an interface that host objects then need to implement to be
cloneable. Extra machinery.

Which one? Tempting to say that this it is a property of the host
language; returning 'null' fits non-strict EcmaScript one might argue,
exceptions its strict mode (such as it is/might become.) Languages that
provide more sophisticated type systems and enforcement might do a
better job. Personally, I think throwing an exception fits in with the
spec's use of them elsewhere (i.e., cross-document and web workers.)

If it is changed back, please leave behind a footnote about the issue ;-)

--sigbjorn | sof at opera.com