Re: The Structured Clone Wars

On Fri, Jul 15, 2011 at 2:50 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:

>
> On Jul 15, 2011, at 10:56 AM, Dean Landolt wrote:
>
>
>
> On Fri, Jul 15, 2011 at 1:30 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:
>
>>
>> On Jul 15, 2011, at 10:00 AM, Jonas Sicking wrote:
>> >
>> > Except that you don't want to do that for host objects. T
>>
> ...
>
>
>> And a cloned JS object is a lot less useful if it has lost it's original
>> [[Prototype]].
>
>
>
> Didn't you just argue you could communicate this kind of information with a
> schema? You couldn't share the actual [[Prototype]] anyway. So you'd have to
> pass the expected behaviors along with the object (this is why a Function
> serialization would be wonderful, but this could be done in a schema too).
>
> Sure, it won't be terribly efficient since (without mutable __proto__ or a
> <| like mechanism in JSON) your worker would have to another key pass to
> tack on the appropriate behaviors. There's no benefit to the branding info
> (again, no shared memory) so I don't really see the problem. Why would this
> JS object be substantially less useful? It just requires a slightly
> different paradigm -- but this is to be expected. The only alternatives I
> can imagine would require some kind of spec. assistance (e.g. a specified
> schema format or a JSON++), which I gather you were trying to avoid.
>
>
> I was only objecting to any argument that starts out by essentially saying
> host objects are have unique requirements.   Anything that is an issue host
> objects is likely to be an issue for some pure JS application.
>


Okay, but what of the assertion itself? Must a cloned JS object must
maintain its [[Prototype]]? I'm just curious as to why.


Generalizations about host objects  are no more or less valid than
> generalizations about pure JS objects.
>
> This issue applies to pure JS object graphs or any serialization scheme.
>  Sometimes language specific physical clones won't capture the desired
> semantics.  (Consider for example, an object that references a resource by
> using a symbolic token to access a local resource registry). That is why the
> ES5 JSON encoder/decoder includes extension points such as the toJSON
> method.  To enable semantic encodings that are different form the physical
> object structure.
>
> The structured clone algorithm, as currently written allows the passing of
> strings, so it is possible to use in to transmit anything that can be
> encoded within a string. All it takes needs is an application specific
> encoder/decoder.  It seems to me the real complication is a desire for some
> structured clone use cases to avoid serialization and permit sharing via a
> copy-on-right of a real JS object graph.



There are alternatives to CoW (dherman alluded to safely transferring
ownership in his post, for instance).


In either case there are contextual issues such as the [[Prototype]]
> problem.  More generally if you have a behavioral based (methods+accessors
> are the only public interface) object model  then you really can't CoW or
> transfer ownership meaningfully and maintain no shared state illusion.
>


By who's definition of meaningful? IIUC you're asserting that directly
sharing context like [[Prototype]] is both important and impossible. I
contend that the behavior-based object model can be shared, if only
indirectly, by completely detaching it from the main thread's "deeply
intertwined, deeply mutable object graph" (to borrow dherman's colorful
phrase). This would almost certainly require spec. support but I can think
of at least a few ways to do it. If something like this were doable it could
open the door for the most efficient structured clone I can think of: no
clone at all.


>  If you define this sharing in terms of serialization then you probably
>> eliminate some of the language-specific low level sharing semantic issues.
>>  But you are still going to have higher lever semantic issues such as what
>> does it mean to serialize a File. It isn't clear to me that there is a
>> general solution to the latter.
>>
>
>
> Why does it matter what it means to serialize a File? For the use cases in
> question (IndexedDB and WebWorkers) there are various paths an app could
> take, why would this have to be spec'ed? What does toJSON do? And does a
> file handle really need to make it across this serialization boundary and
> into your IDB store for later retrieval? I suspect not.
>
>
> Again, just an example and something that structured clone does deal even
> if not in a very precise manner.  I was trying to say that there probably
> isn't a general solution communicate higher level semantic information. It
> needs to be designed on a case by case basis.
>


Indeed, certain applications may require custom handling. But it would be
great if there were an easy and obvious default. It's good enough for JSON,
which is a very similar use case (especially in the context of IDB).

So I'm still curious just how important is it to transmit a faithful
representation of an object, prototype and all, for the WebWorker use case?
I suspect a few compromises can be made to get to an efficient postMessage
that could sidestep Structured Clone entirely. Wouldn't this be a more
desirable outcome anyway?