Re: External communication with SCXML

Le 11 feb 2013 à 18:42, Stefan Radomski a écrit :

> we are about to implement a simple REST interface (in & out) and were pondering about the best way to integrate such a thing into SCXML's concepts. There already is the basichttp ioprocessor available for the type attribute with send, but - as I raised earlier - it will completely ignore the actual result of such a request. One possibility would be to go for a "resthttp" (or similar) type which could deliver the result as an event into the interpreter. This would solve sending requests via SCXML and get at their result.
> 
> As for receiving requests, we need to get them as an event (just as with the basichttp ioprocessor) and be able to reply. Replying could be realized by sending an event to a special #_http.requestId but I'd like to gather some thoughts first. Another alternative is to go for a dedicated invoker that will deliver events and is available to reply to the remote party.
> 
> I understand that all of this can be solved "out-of-draft" but then again, maybe the various implementations could at least provide common concepts. Anyone have some thoughts about this?


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.

In my implementation (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.

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.


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.

			David