The MOO metaphor combined with the idea of `negotiation' between the agent's intentions and the `structure of the world', represented as a set of Linda blackboards storing state information on servers connected over the the Internet allows a simple and secure remote execution mechanism through specialized server-side interpreters.
Implementation of arbitrary remote execution is easy in a Linda + Prolog system due to Prolog's metaprogramming abilities. No complex serialization remote procedure/method call packages are needed. In BinProlog (starting with version 5.75) code fetched lazily over the network is cached in a local database and then dynamically recompiled on the fly if usage statistics indicate that it is not volatile and it is heavily used locally.
As an example, high performance file-transfer (actually known to be faster than well-known http as ftp protocols) is implemented by orchestrating Prolog based remote_run control operations which are used to trigger direct full speed transfers entirely left to optimized C built-ins like sock2file/2:
fget(RemoteFile,LocalFile):- remote_run(RF,fopen(RemoteFile,'rb',RF)), fopen(LocalFile,'wb',LF), term_chars(to_sock(RF),Cmd), new_client(Socket), sock_write(Socket,Cmd), socket(Socket)=>from_sock(LF,_), fclose(LF), sock_read(Socket,_), close_socket(Socket), remote_run(fclose(RF)). from_sock(F,yes):- assumed(socket(S)), sock2file(S,F),!.
Once the basic Linda protocol is in place and Prolog terms are sent through sockets, a command filtering server loop simply listens and executes the set of `allowed' commands.
Despite Prolog's lack of object oriented features we have implemented code reuse with intuitionistic assumptions.
For instance, to iterate over the set of servers forming the receiving end of our `Web of MOOs', after retrieving the list form a `master servers' which constantly monitors them making sure that the list reflects login/logout information, we simply override host/1 and port/1 with intuitionistic implication:
ask_all_servers(ListOfServers,Question):- member(server_id(_,H,P),ListOfServers), host(H)=>port(P)=>ask_a_server(Question,_), fail. ask_all_servers(_,_).
To specialize a generic server into either a master server or a secure `chat-only' server which merges messages from BinProlog users world-wide we simply override the filtering step in the generic server's main interpreter loop.
Implementing agents `roaming over' a set of servers is a simple and efficient high-level operation. First, we get the list of servers from the master server. Then we iterate through the appropriate remote-call negotiation with each site. Our agent's behavior is limited through security and resource limitations of participating interpreters, each having their own command filtering policies.
In particular, on a chat-only server our roaming agent can only display a message. If the local interpreter allows gathering user information than our agent can collect it. If the local interpreter allows question/answering our agent will actually interact with the human user through the local server window.
Such mobile agents are seen as `connection brokers' between participating independent server/client sites. For instance if two sites are willing to have a private conversation or code exchange they can do so by simply using the server/port/password information our agent can help them to exchange.
Note that full metaprogramming combined with source-level mobile-code have the potential of better security than byte-code level verification as it happens in Java, as meaningful analysis and verification of program properties is possible.