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: Thu, 14 Jul 2011 23:30:22 -0500
Message-ID: <CAPh8+ZrBz+k51Wrf+01sfy9_f5RudepiA8axRuEQDuhhJ4cEiQ@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: David Bruant <david.bruant@labri.fr>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
On Thu, Jul 14, 2011 at 2:46 PM, Mark S. Miller <erights@google.com> wrote:
> Ambiguities:
> 1) When the says "If input is an Object object", I assumed it meant 'if the
> input's [[Class]] is "Object" '.
> 2) By "for each enumerable property in input" combined with "Note: This does
> not walk the prototype chain.", I assume it meant "for each enumerable own
> property of input".
> 3) By "the value of the property" combined with "Property descriptors,
> setters, getters, and analogous features are not copied in this process.", I
> assume it meant "the result of calling the [[Get]] internal method of input
> with the property name", even if the enumerable own property is an accessor
> property.

I wrote Mozilla's initial cut at structured cloning, and I resolved
each of these in the same way, except that in 1) I interpreted "If
input is an Object object" to exclude proxies. (We could perhaps
change it.)

Allen Wirfs-Brock write:
> Something that isn't clear to me is which primordials are used
> to set the [[Prototype]] of the generated objects.  It isn't covered in
> the internal structured cloning algorithm.  Perhaps it is, where
> structured clone is invoked.

Consider that in IndexedDB, the "copy" is made at the time the object
is put into the database, and then the copy is used in perhaps a
completely different browser instance. And in the case of postMessage,
the copy is in a totally separate heap that lives on a separate
thread. Perhaps this makes it clearer what structured cloning really
is.

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.

We implement a pair of functions, JS_WriteStructuredClone and
JS_ReadStructuredClone. The latter requires the caller to specify the
global object in which the clone is to be made. That global's
primordial prototypes are used. The actual serialization format is not
exposed to the web.

Back to Mark S. Miller:
> 4) By "corresponding to the same underlying data", I assume it
> meant to imply direct sharing of read/write access, leading to
> shared state concurrency between otherwise shared-nothing event
> loops.

Blobs and Files are immutable. The File API spec says:

"This interface represents *immutable* raw data." [emphasis in original]
http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob

> And finally there's the issue raised by David on the es-discuss thread: What
> should the structured clone algorithm do when encountering a proxy? The
> algorithm as coded below will successfully "clone" proxies, for some meaning
> of clone. Is that the clone behavior we wish for proxies?

The structured cloning algorithm should be redefined in terms of the
ES object protocol. This seems necessary anyway, for precision.

The appropriate behavior regarding proxies would fall out of that;
proxies would not have to be specifically mentioned in the algorithm's
spec.

(Every algorithm that mentions proxies, or really any other object
type, by name is one broken piece of a Proxy.isProxy implementation.)

Cheers,
-j
Received on Friday, 15 July 2011 04:30:58 UTC

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