Marco.Ronchetti@lii.unitn.it
Vincenzo D'Andrea, Laboratorio di Ingegneria Informatica, Via
Zeni 8 38068 ROVERETO (TN) ITALY
Vincenzo.Dandrea@lii.unitn.it
Giancarlo Succi, Dipartimento di Informatica e Studi Aziendali -
Universita' di Trento, Via Inama, 38100 TRENTO ITALY
Giancarlo.Succi@lii.unitn.it
Diego Feltrin, Diploma di Ingegneria Informatica -
Universita' di Trento, Corso Bettini 84, 38068 ROVERETO (TN) ITALY
dfeltrin@sun10.inf.unitn.it
These scripts can be written in any programming language and their main functions are:
Such capability is widely used, and many WWW servers offer services based on CGI.
Our idea is to use these ingredients make yesterday's leftovers appetizing again.
Many old programs (yesterday's leftovers) are still interesting for the
value of the information they control. Now that we are used to point and
click to solve our problems, we find some of their user interfaces
horrible to use (and sometimes we found them horrible also when we did not
have a mouse at our hand...). Sometimes we do not have access to the code,
so we can't change it, and also if we could, the task would be horrible:
unknown languages, undocumented and/or unreadable code etc.
While branches of Computer Science and Practice, e.g. Reverse Engineering
and Reengineering, try to find some way to effectively attack the problem,
it would be interesting to have solutions which, in spite of being
partial, allow us to live better in the meantime.
We believe that WWW allows to attempt a solution, and performed an
experiment on such a problem. In the approach we propose, the old application
is conceptually wrapped into a container (the translator) which gets its outputs
and feeds it with (recoded) user input. The dialog with the user is mediated by
html pages, which can of course present forms or take advantage of features
like clickable images, unleashing programmer's creativity.
The only necessary condition is that I/O of the old application can be
redirected (a standard on a Unix system). The application should therefore
speak to a "translator" process, which in turn speaks to the user by
serving her/him html pages and reading her/his input.
While all this might seem similar to the gateways to WAIS or Gopher servers, we
stress that the concept is different: in this case we are speaking of
applications which were not thought as information providers to remote
users, and also the network itself is not needed !. One
can in fact even imagine a stand-alone system with an http daemon running
to serve local requests, just for the purpose of providing a better user
interface to a bunch of old programs.
In the rest of this section we will briefly sketch how the "translator" can be constructed, outline the problems that can arise, suggest strategies which can be taken to solve them, and indicate possible further research issues. The discussion will not be exhaustive due to the space constraints imposed on these papers.
A necessary step to build a translator consists in describing the old application as a finite state automaton, therefore defining the transition rules. These rules are the guide for writing the translator, which must be programmed so as to be able to recognize (or remember) the current state, and offer HTML pages presenting the actions which can be performed on that state. It would certainly be interesting to be able to make a general, automatic procedure which is able to construct the translator from the automaton definition. We are currently exploring this possibility.
Of course a major point arises: while the WWW protocol is stateless, the application we are wrapping can be (and typically will be) stateful. The history mechanism (which on most browsers allows the user to step back to a previously visited page) can cause confusion to the translator. A simple solution is to warn the user NOT to use the history feature, and to instruct the translator to refuse to serve any unexpected page, reminding the user of the impossibility to use the history. A more sophisticated approach is to instruct the translator to recognize such situations and, if possible, to send to the wrapped application the necessary instructions to go back to the state desired by the user.
A more complex problem arises when two (or more) users attempt to access
the same service, since they would act on the same application! Also in
this case, several solutions can be devised, the simplest of which is to
(kindly) refuse to serve new users until the first has finished her/his job
(or until a time-out has been reached). New users could be recognized since
they would access the first page, although also here the history mechanism
could create problems. Better solutions require to identify the users.
Unfortunately HTTP identification capabilities are limited. Although in fact
the script has access to some environment variables like REMOTE_ADDR, these
are not sufficient to uniquely identify the remote user: the REMOTE_USER variable
is set only if the WWW client supports is, which is not true for too many
browsers.
Luckily, CGI allows for extra information to be embedded in the URL for the
gateway which can be used to transmit extra context-specific information to the
scripts.
We implemented the following solution: when the translator gets
the first request from the user (e.g. an access to the entry page), it
starts a fresh copy of the wrapped application and issues an unique
identifier. This identifier is hard-wired in the page
generated as response to the user (e.g. through the PATH_INFO mechanism described
in [MCC93]). All following interactions with the user will carry the
identifier, therefore allowing the translator to refer to the correct
copy of the application.
Finally, we want just mention in passing that the translator also has the opportunity to look ahead and buffer the informations: whenever it is expected that the user will perform some future action, such action can be performed in advance, therefore achieving an effective improvement of the wrapped application performances.
We therefore started a project in which we built a wrapper which completely masks the CBT interface. We implemented the user identification (not in the sense that we know who the use is, but in the sense discussed above: each user is given an identity at the beginning of the interaction, and such identity is used to make all following interactions consistent). User identification also allows us to serve requests coming from several users by using the same telnet port, therefore enhancing the possibility of access to CBT. The service (still at an experimental stage), as well as the former version can be accessed through the net.
We also implemented the look-ahead idea: for instance when a search by author is made, and the library has more than 14 different books by that author, only the first 14 (i.e. a screenful) are presented to the user. The user will have to explicitly request the next page(s). In such case we look ahead, asking all pages, and presenting to the user the entire information. In this way not only the interaction is more friendly (which was the original goal) but also the information desired is delivered in a shorter time (i.e. the effective performance has been increased).