Indeed. Though it might make sense to define it in terms of "anything
parseable as JSON + blobExtension" even though that's probably not what
will happen internally.
Anyhow, sounds like there is agreement on feature-set which is the
important thing. How it's defined and implemented matters less to me
right now :)
/ Jonas
Aaron Boodman wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
