Re: External communication with SCXML

Hey David,

On Feb 11, 2013, at 7:34 PM, David Junger <tffy@free.fr<mailto:tffy@free.fr>> wrote:

Some of your needs are actually covered by the spec, but if things don't work quite the way we want, it's easier to implement an extension and refine it while using it, than just talk and wait for it to become part of the spec in the first place. If we agree on a particular extension and find that it's widely used, it will most likely be incorporated in the specification afterwards.

Could you elaborate as to which parts are "actually covered by the spec"? There is certainly the possibility that I missed them.

In my implementation (github.com/Touffy/JSSCxml<http://github.com/Touffy/JSSCxml>), which runs in Web browsers, it is not possible to fully implement basichttp so I didn't, and instead I added the <fetch> element (inspired from CCXML) which does what you describe (generates a callback event with the HTTP response), basically it's an SCXML interface to XHR. I haven't implemented namespaced executable content yet so it's not namespaced as it should be.
Have a look at the documentation (http://touffy.hd.free.fr/~touffy/jsscxml/fetch.html) and tell me what you think.
I have already used it in one project and it's quite handy, actually it's easier than writing typical XHR code in JavaScript.

Having a <fetch> element such as yours definitely seems suited to invoke external services and process its results. It is in essence the solution I proposed above, but with a dedicated element for executable content, rather than a special type with <send>. I would support such a thing in our interpreter, though I am indifferent as to whether it ought to be <fetch> or a special ioprocessor. The key point, I guess, is to represent replies as events again.

So that's for one-shot requests with a response, and I believe it could be useful on other platform, even when they have access to basichttp, because the client-server paradigm is a common way to interface with Web services even when you're a server yourself.

Replying could be realized by sending an event to a special #_http.requestId
The spec says the URL you should reply to, when receiving a remote http event, must be included in the _event.origin property.


Yes, but in my case I just have a pending http request from a client. There is no remote URL to reply to. If there were, we could go for <send> again.


I will not get involved with directly listening to any incoming event from anywhere, since it is also impossible for my implementation.

To cover more persistent communication in a way that can also be implemented in the browser, I repeat my earlier suggestion that we take a leaf from the HTML "living standard":
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html

Basically, the EventSource interface describes an Event-firing wrapper object around a persistent and robust HTTP connection. It requires clients to initiate the connection, so an arbitrary server cannot send events without invitation, but peer sharing techniques can be used to let the client know where to connect. I for one would really like if we adopted the same protocol and designed an SCXML executable content extension or <invoke> type based on the EventSource interface.


I will have a look at it. Thank you.

Did anyone else implement something more elaborate than the receiving part of the basichttp ioprocessor, where the interpreter could actually send replies?

Best regards
Stefan