[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Demexp-dev] On web client, XML and ONC RPC and their integration with d

From: David MENTRE
Subject: [Demexp-dev] On web client, XML and ONC RPC and their integration with demexp
Date: Thu, 31 Aug 2006 13:48:07 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)


To put this message into context, Augustin has recently proposed[1] to
make a web interface for demexp using Drupal. One of the main issue of
this proposal and that there is no implementation of ONC RPC (used to
communicate with demexp server) in PHP (and hence for Drupal). However,
Drupal has a XML RPC module[2].

I started to look at this issue[3] and found no easy way to solve

One approach would be to compile the XDR description of demexp protocol
into C using rpcgen(3) and then make a PHP binding to it. While
apparently not too difficult, this approach is not very versatile: if
the protocol is modified, one needs to modify manually the PHP/C

A second approach would be to implement an RPC generator and its
supporting XDR encoding/decoding library for PHP. I haven't much
investigated this approach but it seems to me not a very simple
path. Moreover, beside demexp, I don't think a lot of people in the PHP
community are eager to use ONC RPC. :-)

A third approach would be to implement the XML RPC interface on the
demexp side. This seems doable with current infrastructure. Gerd's has
confirmed me that we could have simultaneously XML and ONC RPC inside
demexp[4] and, it should be possible to use CDuce to implement XML
parsing and generation[5]. However, I'm not entirely satisfied with this
approach: it would necessitate to have two interfaces at the demexp
server, XML RPC and ONC RPC, thus two interfaces to debug, test and
maintain: complexity is the mother of bad engineering.

This leads me to a fourth approach: implement a XML RPC <-> ONC RPC
proxy as an interface between the XML RPC side (Drupal) and the ONC RPC
side (demexp server). It would act as a server on the XML RPC side and
as a client on the ONC RPC side. This approach seems to me nicer because
there is no need for a re-implementation of all server network API: the
same ONC RPC interface is used for both the web and native clients on
the server side. Moreover, such a proxy would be an independant
software, with well defined interfaces, so easier to maintain,
understand and modify.

It remains to see how we could implement this fourth approach. Two
languages comme to mind, OCaml (with CDuce and ocamlrpc) and Python
(with Thomas's RPC module and one of numerous XML RPC Python module). I
don't know which one would be the easier. The ideal approach would be to
have a program that, from the XDR description of the demexp protocol,
generates the code of the proxy, but that might be a little to
complicated at first.

What do you think of it? Any thoughts?

Best wishes,


[2]  Augustin, could you give me a precise reference to it? To its




GPG/PGP key: A3AD7A2A David MENTRE <address@hidden>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A

reply via email to

[Prev in Thread] Current Thread [Next in Thread]