[Tsp-devel] XMLRPC command channel status

[Eric Noulard]

Hi All,

I'm forking a discussion from the tracker
https://savannah.nongnu.org/bugs/index.php?22190
to the list because I find it more appropriate.

The question from Robert (HDV) was:

> Do you mean that the c variant of the client side of the
> xmlrpc interface is not meant to be
> used, but rather the plain old rpc variant?

The story is (Frederik and Stephane should correct me if I'm wrong):

Frederik volunteered to add xmlrpc command channel to TSP
and began with something like
cp tsp/core/rpc tsp/core/xmlrpc + work

The trouble was TSP was meant (by design) to support different command
channels but the C source code was not.
In fact , I did do some work in order to handle simultaneous
multiple command channel but ONLY on the __provider side__.
I did test my work using 2 ONCRPC command channel on the same provider
and this was fine, at least it worked the way I expected.
(see tsp/core/ctrl/tsp_request_handler.[hc])

But when Fred did add the xmlrpc command channel
it was not possible (software architecture missing) for him
to compiled multiple __client-side__ command channel
thus you had to
CHOOSE between either TSP with ONCRPC _OR_ TSP with XMLRPC.
He did it this way because he add no other TSP consumer than
the C ones (client_stdout, ascii_writer etc...).

As a consequence the TSP consumer/provider was compiled
with either ONCRPC __OR__ ONCRPC builtin.

Then Stephane GALLES volunteered to start it's Ruby consumer (lib and test app).
He found better support for XMLRPC than for ONCRPC in Ruby
(I know this language was Rubbish :-)
so that he wanted to reuse the XMLRPC command channel work.

He had some work to do because we did not compile TSP + XMLRPC
very often (and we did add multi-type handling).
After some discussion we found it was a pitty not to do so
(always compile XMLRPC channel).
In the discussion we found that it was easy to authorize
both RPC channels (XML and ONC) on the provider side and
that we should do so (set  BUILD_XMLRPC to ON with CMake).

Moreover we thought it was interesting to have XLMRPC on provider side
and probably XMLRPC on consumer side for script binding
beginning with ruby but it does not seem to be of great interest
to build consumer in C langage with XMLRPC.

Stephane did modify code and CMakeLists.txt accordingly.
The client-side XMLRPC code in C langage is in the source
but as far as I know, uncompiled and unused.

I think we may remove client side XMLRPC code in C alltogether
because no one is compiling it and may be no one have time
to maintain it because it of no use.

Your (all of you) opinions are welcomed.
The question is:
   Should we remove the consumer side XMLRPC C code from
   TSP source.

-- 
Erk