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

Re: The Structured Clone Wars

From: Dean Landolt <dean@deanlandolt.com>
Date: Fri, 15 Jul 2011 11:51:54 -0400
Message-ID: <CAPm8pjpgULX25f3dqEpDJFeG1b08jM=WbT5YQ4XGsFjVnh4B_Q@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: Jason Orendorff <jason.orendorff@gmail.com>, "Mark S. Miller" <erights@google.com>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
> 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.
Received on Friday, 15 July 2011 15:52:30 UTC

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