tklab-tud / uscxml

SCXML interpreter and transformer/compiler written in C/C++ with bindings to Java, C#, Python and Lua
Other
104 stars 54 forks source link

uscxml-browser example purpose unclear #178

Closed catskul closed 4 years ago

catskul commented 6 years ago

So as best I can tell uscxml-browser is meant to be an http interface for the uscxml interpreter run on a scxml file. However the example in the readme file:

./uscxml-browser https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxml

Runs then exits outputting:


[Info] HTTP server listening on tcp/5080
[Info] WebSocket server listening on tcp/5081
[Info] Processing https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxml
[Info] Using cache from '/tmp/uscxml/F7870F036CAC8B249C3650B42E46EEF1.uscxml.cache'
[Log] Outcome: "'pass'"

I've tried it on other scxml files like the example on the wikipedia page as an alternative:

<?xml version="1.0" encoding="UTF-8"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initial="ready">
    <state id="ready">
        <transition event="watch.start" target="running"/>
    </state>
    <state id="running">
        <transition event="watch.split" target="paused"/>
        <transition event="watch.stop" target="stopped"/>
    </state>
    <state id="paused">
        <transition event="watch.unsplit" target="running"/>
        <transition event="watch.stop" target="stopped"/>
    </state>
    <state id="stopped">
        <transition event="watch.reset" target="ready"/>
    </state>
</scxml>

In this case the program stays running waiting for requests:

[Info] HTTP server listening on tcp/5080
[Info] WebSocket server listening on tcp/5081
Available Datamodels:
    ecmascript
    lua
    null
    promela

Available Invokers:
    dirmon  (DirectoryMonitor, http://uscxml.tk.informatik.tu-darmstadt.de/#dirmon)
    scxml   (uscxml, http://www.w3.org/TR/scxml, http://www.w3.org/TR/scxml/)

Available I/O Processors:
    basichttp   (http://www.w3.org/TR/scxml/#BasicHTTPEventProcessor)
    http    (http://www.w3.org/TR/scxml/#HTTPEventProcessor)
    scxml   (http://www.w3.org/TR/scxml/#SCXMLEventProcessor)

Available Elements:
    http://www.w3.org/2005/07/scxml / respond

[Info] Processing watch.scxml
[Info] Using cache from '/tmp/uscxml/ECC6D4BEFBC890A2DBFDA849684D4EF3.uscxml.cache'
Microstep in config: {}
Entering: /scxml[1]
Entering: ready
Stable Config: { /scxml[1], ready }

but then it's completely unclear what request should look like. localhost:5080 returns 404 not found, and the program on the command line prints:

I edited the Http server to output valid "servelets" and get a list:

[Info] Available servelets: debug
[Info] Available servelets: watch.scxml
[Info] Available servelets: watch.scxml/basichttp

None of which produces anything useful if I hit them with the browser.

Is there some other hints as to how the uscxml-browser is supposed to work, what it's purpose is, that I'm missing? Or perhaps I'm doing something obviously wrong?

sradomski commented 6 years ago

uscxml-browser is an interpreter of SCXML files. There is no HTML involved as such. It does listen on a TCP port as required for the basichttp I/O processor mandated by the W3C standard.

If you want a web interface accessible from an HTML browser, there is a uscxml-debugger.html HTML page which communicates with the uscxml-browser instance via long-polling, asynchronous HTTP requests. However that interface lay dormant for quite some time as I failed to find a suitable student to revive it after a substantial refactoring some time last year.

catskul commented 6 years ago

Thanks for the clarification. I'm still not clear on it's purpose, but that's probably just because I'm unfamiliar with the W3 standard on scxml. I'm guessing it's clearer for those who are familiar.