ALFS2 comunication protocol
berndt.matthias at gmx.de
Thu Jul 14 14:20:33 PDT 2005
On Thu, Jul 14, 2005 at 10:07:08AM -0500, James Robertson wrote:
> What is missing in the available implementations that we need?
Many implementations have only the XML part of XMLRPC and ignore the
HTTP part. These ones are more or less good for CGI scripts, when a
HTTP server is available.
XMLRPC-c carry a little HTTP server with their releases, which is based
on Abyss. This implementation does not handle with server threads and
requests a serialized. I don't know, if it's a problem with the HTTP or
the XML/XMLRPC part, but IMHO we need parallel requesthandling.
> What would it take to create our own?
XMLRPC is a protocol for remote procedure calls (uh, what a discovery)
and this point is IMO the main disadvantage. RPC's are designed for
short question - short answer and not for question - long, long work -
answer. If we create our own protocol we can make it satisfy exacly our
> If XMLRPC is built into libxml2 and that is already a runtime dep,
> what all does it require to run?
Sorry, I don't understand your question - may be my bad english. AFAIK
XMLRPC isn't build into libXML2.
The dependecies for our own protocol/implementation? It may depend on
nothing in addition or what ever we want.
> What in the http server does it need?
XMLRPC uses per definition HTTP as transport protocol. So XMLRPC needs
an implementation of HTTP.
> Before we pick an implementation or what to code, we still need
> to come up with what the thing is supposed to do. See this thread:
I know this thread and I'm searching for a solution.
My advice is, if we want minimal depencies, we should create our own
protocol or adopt an available implementation. If we want a standard
protocol, we have to deal with more dependencies and may be some work
for other projects.
I would prefer the first one.
More information about the alfs-discuss