Lets position the work on the trio webserver,
especially creating a framework for the HTTP
protocol and the WS protocol.
There is only one danger in doing these frameworks.
To succumb to the curse of DSL. Already SWI-Prolog
has made the error to popularize Prolog for DSL.
In that they write:
"Its reflective capabilities as well as its
`program is data' view makes it an ideal
platform for domain specific languages (DSLs)
or micro languages, which allows for concise
description of application knowledge and separation
of this knowledge from how it is applied."
http://www.swi-prolog.org/Directions.html#guides
But Prolog is a general purpose language. I have already
seen people claiming that Prolog is exclusively for
DSL, which is utter nonsense.
But what is the goal of a framework for HTTP or WS,
if not a DSL? What is the difference beween pengines and
a HTTP server that can do REST requests. Here are
some answers:
1) The framework here are not in the spirit of some
DSL nonsense. The idea is more to provide object halfs,
for the protocols inbetween. So in distributed programming
an primary concern is to make the recurring connection
between object halfs less painful. So without distribution
an service object and its client looks as follows:
+-----------------------------------+
| +---------+ (::)/2 +-----------+ |
| | Client |--------| Service | |
| +---------+ +-----------+ |
| Host |
+-----------------------------------+
Invokinng the service object is just sending a message to
the service object and getting a response. This is like the
Logtalk send operator (::)/2, also found in Jekejeke Prolog
directly based on ISO core standard modules. If you distribute
the thingy you get two stubs the client stub and the service
stub, and inbetween some protocol:
+--------------------------+ +---------------------------+
| +---------+ (::)/2 +----+|Protocol|+---+ (::)/2 +-----------+ |
| | Client |--------| ||--------|| |--------| Service | |
| +---------+ +----+| |+---+ +-----------+ |
|Host 1 | |Host 2 |
+--------------------------+ +---------------------------+
http://wiki.c2.com/?HalfObjectPlusProtocol
2) So basically pengines and a HTTP framework should
be no difference. A HTTP framework should already allow
addressing service objects inside different Prolog
context. The only thing that might be demanded might
be a management service object, that allows creating,
destroying and managing Prolog contexts. But otherwise
the HTTP framework itself should already be powerful
enough to query service objects inside a Prolog context.