We can do a comparison with some Prolog RPC
prototypes surround SWI-Prolog. This is one
take from Torbjorn Lager:
rpc(URI, Query, Options) :-
pengine_spawn(Pid, [
node(URI),
exit(true)
| Options
]),
options(pid(Pid), Options, Pid),
pengine_ask(Pid, Query, Options),
wait_answer(Query, Pid).
Also comparing with:
https://github.com/Web-Prolog/swi-web-prolog-lite/blob/master/rpc.pl
Main differences when comparing to our recent
Prolog RPC prototype. Some marks of our Prolog
RPC prototype are:
* Pure Erlang primitives realization, no pengine_xxx.
* Pure Erlang primitives realization, no http_xxx.
* No separate pengine_ask needed for the first solution.
* Repeat fail realization of the wait_answer loop.
* Automatic tear down via exit/2 from events in the continuation.
The tear down can be seen in this example where a cut
happens in the continuation. No stop message support is
needed by the remote part of the Prolog RPC:
?- rpc('localhost:3010', father(tom, X)), !.
X = sally
Wont leave any orphaned actor on the remote site.
Instead simply the remote part is immediately exited
with the help of a local setup_call_cleanup/3 usage.
Maybe this complete reduction to the actor model has
a few advantages:
* transport: We can delegate provisioning of some
transport to the actor platform, its not necessary
to write a different rpc for different actor platforms.
As long as the end point that we want to invoke is
representable as what actor platform spawn understands,
rpc/2 should work.
* interleaving: In as far as the actor platform
allows multiplexing, multiple rpc calls can
interleave their messages that are exchanged
between local part and remore part, increasing
resource utilization.
* state: Like actors, the RPC call will optionally
have state. At the remote part of the Prolog RPC
the execution can involve side effects and blocking,
in particular backtracking will always adress the
same actor in the remote site.
Open issues:
security: It might be desirable to identify the
messages that the remote part sends back to the local
part as replies, and have some rules in place. Best
would be if the actor platform would already provide
this security.
I saw that the Java DatagramSocket calls SecurityManager.
I guess its possible to implement policies that an
applet is only allowed to commmunicate with its
originating server, etc... But then maybe we also
want a SecurityManager on the server.