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

Re: The Structured Clone Wars

From: Jason Orendorff <jason.orendorff@gmail.com>
Date: Fri, 15 Jul 2011 12:37:52 -0500
Message-ID: <CAPh8+Zoga9ivgPA+=ORurtZPjag2hiaaPXTzLJuJsRqf2yjL2Q@mail.gmail.com>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
Cc: "Mark S. Miller" <erights@google.com>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
On Fri, Jul 15, 2011 at 10:22 AM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
> On Jul 14, 2011, at 9:30 PM, Jason Orendorff wrote:
>> 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.

Perhaps. Certainly the current spec language isn't ideal.

This algorithm is in the "Here's a bunch of random stuff" section of
the HTML5 standard. Perhaps the ES spec is a better place for it. I'm
not sure.

On Jul 15, 2011, at 12:00 PM, Jonas Sicking wrote:
>2011/7/15 Jason Orendorff <jason.orendorff@gmail.com>
>> The structured cloning algorithm should be redefined in terms of the
>> ES object protocol. This seems necessary anyway, for precision.
>
> Except that you don't want to do that for host objects.

I only meant to say that the structured cloning algorithm should be
specified in precise language, not that the meaning should be
drastically changed. After all this is a deployed standard, right?

If this it were to be done in the style of the ES standard, it would
mean offering an extension point, such as a [[Clone]] internal method,
which cloneable host objects such as File could implement. (I say
[[Clone]], but there are other possibilities.)

-j
Received on Friday, 15 July 2011 17:38:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC