A facility which can be easily built on top of the primitives presented so far is that of ``remote WWW modules,'' i.e., program modules which reside on the net at a particular HTTP address in the same way that normal program modules reside in a particular location in the local file system. This allows for example always fetching the most recent version of a given library (e.g., PiLLoW) when a program is compiled. The CIAO library provides an extended use_module declaration which is identical to the one used in standard systems (e.g., SICStus) but allows using http and ftp addresses when referring to files. For example, the form handler of Section 6.1, if rewritten as
#!/usr/local/bin/lpshell
:- use_module('http://www.clip.dia.fi.upm.es/lib/pillow.pl').
main(_) :-
get_form_input(Input),
get_form_value(Input,person_name,Name),
...
would load the current version of the library each time it is executed.
This generalized module declaration is just syntactic sugar, using
expand_term, for a document fetch, using fetch_url,
followed by a standard use_module declaration. It is obviously
interesting to combine this facility with caching strategies.
An interesting (and straightforward to implement) additional feature
is to fetch remote byte-code (as generally done by use_module),
if available, but this is only possible if the two systems use the
same byte-code (this can normally be checked easily in the bytecode itself).
Also, it may be interesting to combine this type of code downloading
with WWW document accesses, so that code is downloaded automatically
when a particular document is fetched.
This issue is addressed in Section 11.
Finally, there are obvious security issues related to downloading code
in general,
which can be addressed with standard techniques such as security
signatures.