Re: [whatwg] postMessage and serialization
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
Re: [whatwg] postMessage and serialization
On Tue, Feb 12, 2008 at 4:57 PM, Ian Hickson [EMAIL PROTECTED] 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
Re: [whatwg] postMessage and serialization
On Mon, 11 Feb 2008, Aaron Boodman wrote: Has the topic of automatic serialization and deserialization of objects passed across postMessage() come up already? It seems like boolean, number, string, arrays, and objects should be supported. I realize that you can just use a json library, but I wonder why we should force every application that wants to use postMessage() to include a json library when the browser can just do the right thing automatically. 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. 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(). 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] postMessage and serialization
Has the topic of automatic serialization and deserialization of objects passed across postMessage() come up already? It seems like boolean, number, string, arrays, and objects should be supported. I realize that you can just use a json library, but I wonder why we should force every application that wants to use postMessage() to include a json library when the browser can just do the right thing automatically. - a
