Automatic Code Downloading and Local Execution

 

  
Figure 4: Automatic code downloading architecture

In this section we describe an architecture which, using only the facilities we have presented in previous sections, allows the downloading and local execution of Prolog (or other LP/CLP) code by accessing a WWW address, without requiring a special browser. This is a complementary approach to giving WWW access to an active module in the sense that it provides code which will be executed in the client machine. More concretely, the functionality that we desire is that by simply clicking on a WWW pointer, and transparently for the user, remote Prolog code is automatically downloaded in such a way that it can be queried via forms and all the processing is done locally.

To allow this, the HTTP server on the server machine is configured to give a specific mime.type (for example application/x-prolog) to the files which will hold WWW-downloadable Prolog code (for example those with a special suffix, like .wpl). On the other side, the browser is configured to start the wpl_handler helper application when receiving data of type application/x-prolog. This wpl_handler application is the interface to a Prolog engine which will execute the WWW downloaded code, acting as an active module. We now sketch the procedure (see figure 4):

1. The form that will be used to query the downloaded code (and which we assume already loaded on the browser) contains a link which points to a WWW-aware Prolog code file. Clicking on this link produces the download as explained below. Note that for browsers that can handle multipart/mixed mime types (such as most modern browsers), the form and the code file could alternatively be combined in the same document. However, for brevity, we will only describe the case when they are separate. The handler for the form is specified as the local cgi-bin executable wpl_questioner.cgi.
2. As the server of the file tells the browser that this page is of type application/x-prolog, the browser starts a wpl_handler and passes the file to it (in this example by saving the file in a temporal directory and passing its name).
3. The wpl_handler process checks whether a Prolog engine is currently running for this browser and, if necessary, starts one. This Prolog engine is configured as an active module.
4. Then, through a call to a predicate of the active module ``loadcode(File)'' the handler asks the active module to read the code.
5. The active module reads the code and compiles it.
6. wpl_handler waits for the active module to complete the compilation and writes a ``done'' message to the browser.
7. The browser receives the ``done'' message.
8.   Now, when the ``submit'' button in the form is pressed, and following the standard procedure for forms, the browser starts a wpl_questioner process, sending it the form data.
9. The wpl_questioner process gets this form data, translates it to a dictionary FormData and passes it to the active module through a call to its exported predicate answerform(FormData,FormReply).
10. The active module processes this request, and returns in FormReply a WWW page (as a term) which contains the answer to it (and possibly a new form).
11. The wpl_questioner process translates FormReply to raw HTML and gives it back to the browser, dying afterwards. Subsequent queries to the active module can be accomplished either by going back to the previous page (using the ``back'' button present in many browsers) or, if the answer page contains a new query form, by using it. In any case, the procedure continues at 8.

The net effect of the approach is that by simply clicking on a WWW pointer, remote Prolog code is automatically downloaded to a local Prolog engine. Queries posed via the form are answered locally by the Prolog engine.

There are obvious security issues that need to be taken care of in this architecture. Again, standard authentication techniques can be used. However, since source code is being passed around, it is comparatively easy to verify that no dangerous predicates (for example, perhaps those that can access files) are executed. Note again that it is also possible to download bytecode, since this is supported by most current LP/CLP systems, using a similar approach.