Aaron Boodman wrote:
Passing booleans, numbers and strings is trivial using the current API.
Passing arrays of booleans and numbers is trivial too.
Passing objects, or arrays of strings, arrays, or objects, is more
complex, but as you point out, it can be done using JSON libraries. Since
it is likely that JSON will be supported natively by UAs in due course, it
seems better to wait for that support rather than adding type support to
postMessage().
I've seen performance problems using JS-based JSON libraries with
Gears workers. In those cases, the developer had to revert to hacky
custom message formats where what he really wanted was to pass an
object.
Someday, all browsers will have fast JSON support built in, but that
will be awhile for IE. Gears could implement postMessage today, but
we've looked into implementing fast JSON support and it seems
difficult to do much better than you can do with script without access
to the script engine internals.
Seems like you're advocating requesting that browsers (IE) add one
feature (JSON postMessage) to make up for lack of another feature (built
in JSON)? Wouldn't it then be better to standardize a way to do JSON
since that could benefit many other features too, such as JSON in DOM
storage and JSON over XMLHttpRequest.
It seems that most messages will consist either of simple strings, or of
complex data structures (objects). Reconstructing JS objects is not a
trivial operation; you have to worry about references into other parts of
the structure, getters and setters that hang or throw or return infinite
arrays, functions, members that aren't enumerable, etc. I'd rather not go
down that rat hole with v1.
You'll have these problems with JSON too though, right? Whatever the
rules are, we'll have to figure them out eventually.
Right, but trying to figure it out now would stall implementation of the
existing specification, one which already have several implementations
under way and seems very useful.
/ Jonas
