W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: The Structured Clone Wars

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Fri, 15 Jul 2011 09:23:13 -0700
Cc: Jason Orendorff <jason.orendorff@gmail.com>, "Mark S. Miller" <erights@google.com>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
Message-Id: <523413C1-5F5C-4DBE-AEDE-8934214AEECE@wirfs-brock.com>
To: Dean Landolt <dean@deanlandolt.com>

On Jul 15, 2011, at 8:51 AM, Dean Landolt wrote:

>> It's serialization.
>> Or, it's a spec fiction to explain and codify the Web-visible effects
>> of serialization and deserialization without specifying a
>> serialization format.
> As such, it seem like this may be a poor specification approach.  Translation to/from a static serialization format would make clear that there is no sharing of any active object mechanisms such as prototype objects. This is not clear in the current specification. If the specification did use an explicit serialization format in this manner then certainly a valid optimization in appropriate situations would be for an implementation to eliminate the actual encoding/decoding of the serialized representation and to directly generate the target objects.  However, by specifying it terms of such a format you would precisely define the required transformation.  
> If you didn't want to be bothered with inventing a serialization format solely for specification purposes you could accomplish the same thing by specify structured clone as if it was  a transformation to/from JSON format
> JSON alone may not be enough, but it shouldn't be too troublesome to specify a slightly enhanced es-specific JSON extension that includes serializations for undefined, NaN, Infinity, -Infinity, etc. And naturally, support for Date, RegExp and Function would be a huge boon. If a referencing technique were addressed this could even include a <| equivalent to address the [[Prototype]] issue Allen mentioned.
> In this context some of the limitations intentionally imposed in JSON are unnecessary, so why saddle the web platform with them? A more expressive standardized serialization would be useful across the board.

JSON + an appropiate schema  is enough.  You can define a JSON encoded schema that deals with undefined, NaN, etc. as well as circular object references, property attributes, and other issues.  For example see https://github.com/allenwb/jsmirrors/blob/master/jsonObjSample.js for a sketch of such a schema.

For structured clone usage cases that is all you need.  

I'm less convinced that one standardized universal JS object serialization format is such a good idea.  There are lots of application specific issues involved in object serialization and to create a universal format/serializer/deserializer you have to make the policy that are applied highly parameterized. I think it might be better to leave that problem to library writers.


Received on Friday, 15 July 2011 16:23:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC