Re: An IDL for SCXML interpreters

--001a1141b2c457168e0528b2d2d5
Content-Type: text/plain; charset=UTF-8

On Fri, Jul 3, 2015 at 4:01 PM, Stefan Radomski <
[email protected]> wrote:

> Hey there,
>
> [explicitly bcc'ing David, Jacob and Zjnue for I know that they maintain
> SCXML implementations] - this post is pertaining to action point 1 from my
> previous mail:
>
> 1. An Interface Description Language (IDL) for SCXML interpreters.
> 1.1 For simple life-cycle and interpretation of state-charts.
> 1.2 A set of hooks for (on-line) visualisation.
> 1.3 A set of hooks for (on-line) modelling / debugging.
>
> For now, I'd like to focus on point 1.1, but we ought to keep the others
> in mind and maybe eventually extend our ambitions. At least 1.2 is very
> useful as it would allow or a common visualisation. I hereby propose a
> first sketch for an Interface Description Language (IDL) for SCXML (see
> below). It will only allow to instantiate interpreters, run them and
> deliver events. A typical session would look like this:
>
[..]

Hi everyone,

First off, Happy New Year to everyone here and hope it is a remarkable one
for SCXML!

Secondly, huge apologies for the long silence, especially after explicit
inclusion in this very interesting conversation and topic. It was purely
circumstantial and hope it did not cause any offense or slow down these
noble and important efforts towards interoperability.


> // central place to get interpreter instances
> interface Implementation {
> Interpreter fromURI(in String uri) raises(Exception);
> Interpreter fromXML(in String xmlString) raises(Exception);
> Interpreter fromDOM(in Node scxmlRoot) raises(Exception);
> }
>
[..]

While even more rusty on the subject now than before, the one aspect of an
IDL I did have to consider with some of my system targets was how to define
the arguments for the process. For say the cpp process, hscxml_cpp, the
arguments could be specified after a -src, -content, etc, therefore using
similar semantics to the interface proposed above. Yet, it would be good to
know the agreed definition for such system process input, so that one could
test drop-in replacements.

All for now I'm afraid, hope to get back onto these interesting subjects.

Much appreciation for and fun and success with all the efforts!

Best regards,
Zjnue

--001a1141b2c457168e0528b2d2d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jul 3, 2015 at 4:01 PM, Stefan Radomski <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">radoms=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">



<div style=3D"word-wrap:break-word">
Hey there,<br>
<br>
[explicitly bcc&#39;ing David, Jacob and Zjnue for I know that they maintai=
n SCXML implementations] - this post is pertaining to action point 1 from m=
y previous mail:<br>
<br>
1. An Interface Description Language (IDL) for SCXML interpreters.<br>
1.1 For simple life-cycle and interpretation of state-charts.<br>
1.2 A set of hooks for (on-line) visualisation.<br>
1.3 A set of hooks for (on-line) modelling / debugging.<br>
<br>
For now, I&#39;d like to focus on point 1.1, but we ought to keep the other=
s in mind and maybe eventually extend our ambitions. At least 1.2 is very u=
seful as it would allow or a common visualisation. I hereby propose a first=
 sketch for an Interface Description
 Language=C2=A0(IDL) for SCXML (see below). It will only allow to instantia=
te interpreters, run them and deliver events. A typical session would look =
like this:<br></div></blockquote>[..]<br><br>Hi everyone,<br><br>First off,=
 Happy New Year to everyone here and hope it is a remarkable one for SCXML!=
<br><br>Secondly, huge apologies for the long silence, especially after exp=
licit inclusion in this very interesting conversation and topic. It was pur=
ely circumstantial and hope it did not cause any offense or slow down these=
 noble and important efforts towards interoperability.<br><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:b=
reak-word"><font face=3D"Courier">
// central place to get interpreter instances<br>
interface Implementation {<br>
<span style=3D"white-space:pre-wrap"></span>Interpreter fromURI(in String u=
ri) raises(Exception);<br>
<span style=3D"white-space:pre-wrap"></span>Interpreter fromXML(in String x=
mlString) raises(Exception);<br>
<span style=3D"white-space:pre-wrap"></span>Interpreter fromDOM(in Node scx=
mlRoot) raises(Exception);<br>
}<br></font></div></blockquote><div>[..]<br><br>While even more rusty on th=
e subject now than before, the one aspect of an IDL I did have to consider =
with some of my system targets was how to define the arguments for the proc=
ess. For say the cpp process, hscxml_cpp, the arguments could be specified =
after a -src, -content, etc, therefore using similar semantics to the inter=
face proposed above. Yet, it would be good to know the agreed definition fo=
r such system process input, so that one could test drop-in replacements.<b=
r><br></div><div>All for now I&#39;m afraid, hope to get back onto these in=
teresting subjects.<br><br></div><div>Much appreciation for and fun and suc=
cess with all the efforts!<br><br></div><div>Best regards,<br></div><div>Zj=
nue<br></div><div><br></div></div></div></div>

--001a1141b2c457168e0528b2d2d5--