- From: Andreas Gansen <c64zottel@gmail.com>
- Date: Wed, 29 Jan 2014 11:33:56 +0100
- To: Jim Barnett <jim.barnett@genesys.com>
- Cc: Michael Bodell <bodell@247-inc.com>, David Junger <tffy@free.fr>, Voice Public List <www-voice@w3.org>
Hello Jim, I am very fine with the responses. Thank you. Andreas On 29 January 2014 00:31, Jim Barnett <jim.barnett@genesys.com> wrote: > Andreas, > Are you satisfied with David and Michael's responses? At this point in the process, we do not want to entertain substantive revisions to the specification, because we are trying to get version 1.0 finished, and the only way to do that is to freeze the spec. We will be happy to consider significant revisions in a future versions of the specification. > > Please let us know if you are satisfied with this response. If we do not hear from you by February 5th, we will assume that you are. > > Best, > Jim Barnett > > -----Original Message----- > From: Andreas Gansen [mailto:c64zottel@gmail.com] > Sent: Tuesday, January 28, 2014 5:01 PM > To: Michael Bodell > Cc: David Junger; Voice Public List > Subject: Re: Suggestions for onentry/onexit tags > > Hi, > > Hm, I viewed it more in sense of a function call, but it is actually an ordered list of handlers. Now I see also the flexibility through Chapters 4 and 5, which makes it possible to construct easily my function-like interpretation by using <script src..> > > @David: Thanks for your Master-Thesis. Is your performance test setup somewhere online? > > I really appreciate your help. > > Tusen takk, > > Andreas > > > > > On 28 January 2014 21:08, Michael Bodell <bodell@247-inc.com> wrote: >> I agree with David quite strongly that for "non-instant" actions >> invoke is the way to go, and that mid statemachine derefercing to src >> (at least outside send/invoke) is best avoided where possible. >> >> >> >> The multiple handlers currently in the specification is more forgiving >> if you allow xinclude or other preprocessing tricks to combine of >> states and handlers (or even the useful but old school copy/paste >> method of combination). The semantics to an interpreter are clearly >> specified and a human reader/writer should be able to understand what >> multiple onentry/onexit handlers mean and do. Multiple handlers (or >> "listeners") is also something other systems support (like DOM 3 >> eventing), even if the bubble, target, capture algorithm is different >> than the statechart/state machine algorithm present in SCXML. >> >> >> >> From: David Junger [mailto:tffy@free.fr] >> Sent: Tuesday, January 28, 2014 9:11 AM >> To: Voice Public List >> Subject: Re: Suggestions for onentry/onexit tags >> >> >> >> 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). >> >> >> >> David > >
Received on Wednesday, 29 January 2014 10:34:25 UTC