W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2014

Re: Suggestions for onentry/onexit tags

From: David Junger <tffy@free.fr>
Date: Tue, 28 Jan 2014 18:10:38 +0100
Message-Id: <910AF2A8-0830-4549-BA45-097FDBDC39DB@free.fr>
To: Voice Public List <www-voice@w3.org>
Le 28 jan 2014 à 14:16, Andreas Gansen <c64zottel@gmail.com> a écrit :

> <action paralell="1" >
> <action paralell="3" >
> All actions with parallel 1 can be run simultaneously, while 1 runs before 3.
> In times of multicores a valuable feature.

Actions should always be very quick. It's the way SCs are designed. If a long process (or a dozen, or a hundred) should be run, use <invoke> instead, or actions that start a process but return immediately. In fact, <invoke> is quite good for managing multiple child processes, and you can easily add custom parameters to specify process priority. Look into it.

> >There are standard ways to do templating in XML. I think it would be better to reuse those for interpreters that wish to support such things.
> I can't see the template pattern here. It is more a catalogue of functions which can be referenced.
> But I am sure it can be reconstructed with xml.

Well, executable content in SCXML is made of XML, not functions, so if you want to make it reuseable you need to reference an XML structure somehow…

> Having the code blocks outsourced would be an optional feature to share between applications/statecharts. Hence it could also be used to reduce bandwith usage of you see it as a library.

… On the other hand, if you are only using scripts for executable content, you can of course use <script src> which is already defined in the spec, or, even better when available, load libraries into the parent context before runing the SCs, and make them available to the SCs using interpreter-specific functionnality (e.g. passing a dictionnary of JavaScript objects to the SCxml constructor in JSSCxml: http://www.jsscxml.org/api.html#constructor).


Received on Tuesday, 28 January 2014 17:11:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:01 UTC