Re: The Structured Clone Wars

On Fri, Jul 15, 2011 at 1:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Jul 15, 2011 at 1:26 AM, Tom Van Cutsem <tomvc.be@gmail.com>
> wrote:
> > 2011/7/15 Jason Orendorff <jason.orendorff@gmail.com>
> >>
> >> Back to Mark S. Miller:
> >> > 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.
> >
> > +1. This also matches with the behavior of JSON.stringify(aProxy):
> > serializing a proxy as data should simply query the object's own
> properties
> > by calling the appropriate traps (in the case of JSON, this includes
> > intercepting the call to 'toJSON').
>
> Except that you don't want to do that for host objects. Trying to
> clone a File object by cloning its properties is going to give you an
> object which is a whole lot less useful as it wouldn't contain any of
> the file data. Once we define support for cloning ArrayBuffers the
> same thing will apply to it.
>
> This might in fact be a big hurdle to implementing structured cloning
> in javascript. How would a JS implementation of structured clone
> determine if an object is a host object which would loose all its
> useful semantics if cloned, vs. a "plain" JS object which can usefully
> be cloned?
>

Through the use of a *serializable* predicate -- perhaps toJSON, as you
recognized in your response Dave's referenced post. Is it really a problem
if host objects don't survive in full across serialization boundaries? As
you say "All APIs that use structured cloning are pretty explicit. Things
like Worker.postMessage and IDBObjectStore.put pretty explicitly creates a
new copy." If you expect host objects to survive across that boundary you'll
quickly learn otherwise, and it won't take long to grok the difference.

Java draws a distinction between marshalling and serialization which might
be useful to this discussion:

http://tools.ietf.org/html/rfc2713#section-2.3

To "marshal" an object means to record its state and codebase(s) insuch a
> way that when the marshalled object is "unmarshalled," a copy of the
> original object is obtained, possibly by automatically loading the class
> definitions of the object.  You can marshal any object that is serializable
> or remote (that is, implements the java.rmi.Remote interface).  Marshalling
> is like serialization, except marshalling also records codebases.
>

I agree with the conclusion in Dave's post:

A more adaptable approach might be for ECMAScript to specify “transmittable”
> data structures.
>

But the premise suggests the need for marshalling where we can get by
without preserving all this environment information. If you don't like the
behavior toJSON is already metaprogrammable, and as Allen suggests a schema
could be used to capture deeper type information -- it could also
communicate property descriptor config. I'd rather a fully self-describing
format exist but I concede it's unnecessary.