RE: Sharing state with invoked SCXML interpreters [was DOM in _event.data and KVPs]

Section 6.4.4 of the spec makes it clear that there is no sharing of state between a parent and child.  That has always been the intent.

- Jim

-----Original Message-----
From: Michael Bodell [mailto:bodell@247-inc.com] 
Sent: Wednesday, April 03, 2013 4:45 AM
To: Stefan Radomski; David Junger
Cc: VBWG Public (www-voice@w3.org)
Subject: RE: Sharing state with invoked SCXML interpreters [was DOM in _event.data and KVPs]

I strongly agree that there should be no sharing of state between a parent and a child.  It breaks the state machine encapsulation.  There were some who wanted nice default handling and syntactic sugar where invoked variables of the same name would be automatically updated in an implicit finalize if the called statemachine returned the changed names, but always, always, always it was the case that absolutely nothing should be shared between different state machines and that everything should be communicated through events and data attached (by value) to those events.

________________________________________
From: Stefan Radomski [radomski@tk.informatik.tu-darmstadt.de]
Sent: Wednesday, April 03, 2013 1:40 AM
To: David Junger
Cc: VBWG Public (www-voice@w3.org)
Subject: Sharing state with invoked SCXML interpreters [was DOM in  _event.data and KVPs]

I think that this deserves a dedicated thread.

TLDR: I argue that there is absolutely no sharing of state between a parent and an invoked SCXML interpreter. Everything is synchronized via events and initialized via param, content and namelist.

On Apr 2, 2013, at 7:22 PM, David Junger <tffy@free.fr> wrote:

>>>> As the expr attribute of content is already subject to evaluation by the datamodel and it's somewhat obvious to return JSON for nested ECMAScript data structures in expr
>>>
>>> ECMAScript objects don't map to JSON in general. And passing actual ECMAScript references to local targets is often preferable even when the structure can be stringified.
>>
>> Huh? I was under the impression that e.g. an invoked SCXML session does not share the datamodel with its parent?
>
> Indeed it doesn't. And sharing objects is not the same as sharing variables (each datamodel has its own reference, possibly in a different location, to the same object). But something is shared, and it is true that SCXML sessions theoretically shouldn't share their data. Still...

I think the distinction between reference and variable is a technicality which still assumes that there is sharing of memory of any kind which should not be assumed. If you want something passed to the invoked SCXML session, you send it via param or namelist - if you want something back, you send to #_parent. This is where we pass JSON if the object to be passed is indeed of type object.

>> In fact it could run on a completely different host. So passing "references to local targets" would just end up as a potentially undeclared identifier in the other component, if I understood you correctly.
>
> Of course, for remote targets there is no choice but to stringify the objects as best you can.
>

But it should be up to the interpreter to decide where to run invoked sessions. This is no longer possible if you assume any kind of sharing between the parent and the invoked session. You would have different runtime semantics depending on whether the interpreter decided to start the SCXML session on another host or run in the same environment.

>> It might work if you cannot separate datamodels due to running in the same JS context, but it is nothing the standard allows as far as I read it.
>
>
> Surely you can have your JS runtime create as many global contexts as you like, while still being able to share objects betweeen them. I do it for JSSC by creating hidden <iframes>, which have their own global Window. You run a separate v8 for each session?

Most definitely yes, we create a new v8 context for every SCXML instance. There is no sharing of state between the invoked component and the parent. If you want to synchronize, you pass params to invoke or send events.

>
> I don't think it's much of a problem. SCXML interpretation is synchronous so there is no risk of race conditions. The author just needs to be aware that it is the same object, not a copy. It is normal JavaScript behavior (you can pass objects between windows by reference if the security restrictions allow it) so they wouldn't be surprised. And the spec says that values can be any value allowed in the datamodel. Well, references are values in ECMAScript.
>

Our nested SCXML sessions are not synchronous (and the draft implies at various points that they are not) - we do start a dedicated thread. If the invoked entity is of type "voicexml" or "html", you wouldn't assume the invoked component to run synchronously? If you do, you limit the design space severely, especially with regard to the W3C MMI arch [1], where SCXML is supposed to model control documents.

> There are good reasons to allow sending references. Obviously, it's much faster than copying a complex object and it saves memory. It also preserves all the prototype chains and references.

You might get away with a copy-on-write approach if you are running in the same runtime but the general case should not share any data at all. Why would you invoke a nested SCXML session at all if you are going to use the same datamodel (or allow references into it) and run in the same environment anyway, why not just use a nested state in a parallel?

Best regards
Stefan

[1] http://www.w3.org/TR/mmi-arch/

Received on Wednesday, 3 April 2013 12:32:24 UTC