[whatwg] postMessage and serialization

On Tue, Feb 12, 2008 at 4:57 PM, Ian Hickson <ian at hixie.ch> wrote:
>  This was originally how the DOM Storage API worked, but there was
>  significant pushback on this, resulting in the current string-only
>  approach. When I came to writing the postMessage API, I considered that
>  feedback and decided not to bother even trying.

I see. One difference between DOM Storage and postMessage is that with
DOM Storage at least you had name and value separated out. For
postMessage you just get a single value field.

>  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.

>  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.

- a

Received on Thursday, 14 February 2008 09:54:32 UTC