[whatwg] JSON support for worker postMessage

[Aaron Boodman]

Yeah definitely.

You said: "We'll probably have to create further JSON extensions to
support that."

My point is that there is no need to change JSON at all if we ever add
blobs to the list of supported types. Even if you happen to use JSON
internally for the implementation now, you could change it to use some
other serialization format in the future.

Basically, I don't think that just because you can pass a blob via
postMessage, that necessarily means you need to be able to serialize a
blob to JSON. Blobs might be very large, so it might not even make
sense to allow serializing them to JSON.

- a

On Mon, Nov 17, 2008 at 8:18 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> Well, you'd probably want to support things like
>
> w.postMessage({ command: "do cool thing",
>                data: myBlob });
>
> / Jonas
>
> Aaron Boodman wrote:
>>
>> If you support worker.sendMessage(<stuff>), where <stuff> is defined
>> by convenience to be: whatever you are allowed to send
>> JSON.stringify(), then you could expand this in the future to also
>> allow blobs w/o changing anything about JSON.
>>
>> - a
>>
>> On Mon, Nov 17, 2008 at 8:10 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> Indeed. Blobs is a great idea. We'll probably have to create further JSON
>>> extensions to support that.
>>>
>>> / Jonas
>>>
>>> Aaron Boodman wrote:
>>>>
>>>> +1, because I think it will be useful to pass other things to workers
>>>> that JSON cannot represent (blobs) in the future.
>>>>
>>>> - a
>>>>
>>>> On Mon, Nov 17, 2008 at 8:03 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Ben just wrote up a patch to support JSON objects as well as primitive
>>>>> values (0, null, false, etc) to be passed to and from workers using
>>>>> postMessage.
>>>>>
>>>>> Wanted to see what the reactions to this was. Is it a good idea or not?
>>>>>
>>>>> I seem to recall this coming up in the past in the original feedback
>>>>> about
>>>>> what features people wanted.
>>>>>
>>>>> The technical details are as follows:
>>>>> Any of the following values are passed by value as-is:
>>>>> * strings
>>>>> * numbers
>>>>> * booleans
>>>>> * undefined
>>>>> * null
>>>>>
>>>>> Anything else is passed to JSON.stringify (defined by Ecmascript drafts
>>>>> here[1]). If calling JSON.stringify throws the same error will be
>>>>> thrown
>>>>> by
>>>>> the function. Otherwise the message event fired on the other 'side'
>>>>> will
>>>>> contain the result of JSON.parse.
>>>>>
>>>>> / Jonas
>>>>>
>>>
>
>