Conclusion
Step procedure, it can potentially be used via
WWW. The application process will usually be launched from a
script invoked by the http server, in response to
a specially formatted query.
Most http server software now support a standard mechanism (the Common Gateway Interface) to run external applications. The URL used with such a mechanism can include information that will be passed to the external application, along with query information that a form-based document would generate. The output of the external application is then used to create the document that is sent back to the client viewer.
In our case, the server will first invoke a shell script that will analyze the query sent by the client viewer and either spawn a new process whenever a new "simulation" is started, or pass the query to the spawned process when the user is stepping through an example program that has already been started.
A portion of the URL used to refer to an example program will thus contain the process Id of the application, another portion will contain the name of the application, and a third portion will contain the name of the machine on which the process is running. When an application has to be started, the process Id is nul. Once it has been started, the HTML output of the application spawned process will include its own process Id in the URL of the ACTION tag of the form structure representing the "control panel." This process Id, along with the machine name, can be used to pipe information between the server script and the appropriate spawned process, thus allowing the server to run many such spawned processes at the same time, possibly on different machines.
One problem that needs to be dealt with is then the elimination of spawned processes that are not needed anymore, even though the program has not reached its end, because the user has moved to other WWW documents or quitted the viewer. The solution we have adopted is to use a timer signal that will wake up a spawned process if the latter doesn't get reactivated by a user query within a certain time limit. If such a timeout occurs, the spawned process will terminate, thus freeing the system resources it was using.
It should be noted that, with the scheme we used in our project, it doesn't make sense to save the URL of an intermediate state of such remotely executable applications, since the process Id is included in the URL, and this Id is not meaningful anymore once the application has finished executing. One can therefore ask oneself whether it is desirable to use such a scheme. In our case, where all the algorithms were already written, the scheme we chose had the advantage of simplicity, since all the algorithms could be adapted with minimal effort.
For applications that have to be developped from scratch, an alternative would be to have the remote applications written as finite state machines and have the URL hold all the information necessary to execute the next step of the automaton. This would make the URL really universal, at the expense of more complex client-server queries.
Conclusion
Site Hosting: Bronco