taskTransport Sample Protocol - Tasks: task #5703, Implement XML-RPC command channel


You are not allowed to post comments on this tracker with your current authentification level.

task #5703: Implement XML-RPC command channel

Submitted by:  Eric NOULARD <erk>
Submitted on:  Thu Jul 6 07:46:08 2006  
Category: tsp coreShould Start On: Wed Jul 5 22:00:00 2006
Should be Finished on: Wed Jul 5 22:00:00 2006Priority: 5 - Normal
Status: In ProgressPrivacy: Public
Percent Complete: 90%Assigned to: Stephane GALLES <sgalles>
Open/Closed: OpenEffort: 0.00

(Jump to the original submission Jump to the original submission)

Wed Feb 28 09:12:45 2007, comment #10:

>> 2) drop the dyn lib into appropriate place

>Are such places defined anywhere?
>If not, I'd go for

I agree with those locations with some
others like:
$TSP_PLUGINS_PATH if it is defined.

We should agree for search order to
be able to handle priority

I would suggest:


Those PATH and env var may (?should?) be used
for all kind of TSP forthcoming plugins
(BB plugins, Targa Plugins, TSP Core plugins).

>The process would then be:
>foreach (dir) {
>try to open a lib named librequest_XYZ.so
>foreach (lib) {
>try to dlsym(TSP_XYZ_request),
>if (sym defined)

Yes I agree with this scheme, but we should handle
the case of multiple instance of same lib found
in several places something more like:

for each (dir)
try to open a lib named librequest_XYZ.so
then go on with previous process.

we should agree on naming convention for those lib/plugins.

As a sidenote I designed "request handler API"
in order to be able to 'hot-add' request handler
the idea is to trigger dyn lib load with something
like a SIGHUP handler (like most daemon do)
that would rescan for no already
loaded dynlib and then call

If we want to achieve this (which may be too much :))
the process should include a test in order to avoid
to load the same library twice.

In the end since this mechanism is clearly DANGEROUS for
the average real time provider, the default behavior should
be not to handle the "hot-plug" behavior.

Eric NOULARD <erk>
Project Administrator
Tue Feb 27 01:36:08 2007, comment #9:

I just wanted to add that I left the task at 90% because there's still something to be modified in order to have the XMLRPC channel display its URL on stdout when the provider is started. For now, only the RPC channel displays its URL, the XMLRPC channel displays an empty URL (nevertheless everything is perfectly functional)

(by the way I was (nicely !) surprised to see how easy it was to make both channels work simultaneously, just a few modified or uncommented lines and I was done, thanks to the very user friendly command channel registering scheme already in place).

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Mon Feb 26 22:33:18 2007, comment #8:

Nice work, indeed!

> 2) drop the dyn lib into appropriate place

Are such places defined anywhere?
If not, I'd go for

The process would then be:
foreach (dir) {
try to open a lib named librequest_XYZ.so
foreach (lib) {
try to dlsym(TSP_XYZ_request),
if (sym defined)

Frederik Deweerdt <deweerdt>
Project Administrator
Mon Feb 26 21:55:52 2007, comment #7:

Simultaneous XML-RPC + ONC-RPC is just great!!!
It is just what we wanted to do 5 years ago during TSP design :))
I really want to see it running.

You did it the right way by registering second
request handler in

I just wanted to comment further that there one
last step to do making each request_handler a dynamic
library which may be (automatically) loaded if found.
I really don't ask you (=Stephane) to do it but anyone
with spare time may try this.

The idea behind this is the following,
if you want to implement your own TSP request handler
(CORBA, SOAP, custom cryptographic authenticated access etc...)
you may offer it as a plugin to ANY already working TSP provider.
You'll have to

1) build your dynamic lib containing
the TSP_xxxx_request structiure

2) drop the dyn lib into appropriate place

3) restart provider.

Now the provider may handle request using the new
command channel.

We are not so far from this, which is just "fun"
my opinion though :))

Eric NOULARD <erk>
Project Administrator
Mon Feb 26 19:35:20 2007, comment #6:

commited : When the compilation with the XMLRPC channel is ON, the RPC channel is not turned off anymore (both can be used simultaneously).

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Tue Feb 20 21:12:19 2007, comment #5:

offset supporté dans la partie XMLRPC, et dans la partie Ruby. Reste à pouvoir compiler en même temps la canal XMLRPC et le canal RPC

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Mon Aug 14 03:39:26 2006, comment #4:

Dans le code du serveur XMLRPC j'ai ajouté le renvoi du type, ce qui m'a permis de faire fonctionner le multi - type dans le client Ruby. Bientot les tableaux.

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Wed Jul 19 11:32:32 2006, comment #3:

Au fait, J'ai ajouté une CMakeLists.txt pour le tsp_stub_server qui n'en avait pas. Justement parceque l'exemple de Rubytsp est fait pour fonctionner avecle tsp_stub_server.

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Wed Jul 19 07:46:42 2006, comment #2:

J'essaierais de faire un petit essai sous peu.

Eric NOULARD <erk>
Project Administrator
Wed Jul 19 00:55:23 2006, comment #1:

Le merge du patch de fred est fait. La compilation peut se faire avec


se qui active le canal XMLRPC (mais qui pour l'instant désactive le canal RPC)

Le client RUBY fonctionne de nouveau avec les doubles (au prix de quelques FIXME aux quels je vais m'atteler).

Stephane GALLES <sgalles>
Project MemberIn charge of this item.
Thu Jul 6 07:46:08 2006, original submission:

La tache a ete commencee by Fred. D il y a de ca quelques temps
Le dernier patch dispo est la:

L'objectif principal est que le canal XML-RPC soit
compile de facon systematique dans la lib provider.

Le canal XML-RPC cote consumer (en C) ne peut pas
etre compile systematiquement car pour l'instant
le cote consumer ne permet pas le multi-canal.

Donc cote consumer a priori ne rien faire en C pour
l'instant. Les consumers XML-RPC seront prioritairement
en script (Ruby, Python, TCl etc...) ou Java.

CE qui reste a faire

> De mon point de vue, les tâches qui restent à faire sont:
> 1) Commiter le patch que j'avais envoyé dans le temps


> 2) Faire les modifs nécessaires dans les CMakeLists.txt pour permettre
> le choix rpc/xmlrpc
> 3) Ajouter les multi-types
> 4) Supporter des providers rpc et xmlrpc

Stephane Galles a dit:
OK, je peux prendre ces tâches dans cet ordre. Selon mon degrés
d'avancement je pourrai passer le relais à qui le désir selon l'intéret
pour un sujet ou la disponibilité de chacun, ou encore l'urgence de voir
une de ces tâches terminée plus tôt.

Eric NOULARD <erk>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by deweerdt (Posted a comment)
  • -unavailable- added by erk (Posted a comment)
  • -unavailable- added by sgalles (Posted a comment)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue Feb 20 21:12:18 2007sgallesPercent Complete60%=>90%
    Mon Aug 14 03:39:26 2006sgallesPercent Complete50%=>60%
    Wed Jul 19 00:55:23 2006sgallesPercent Complete40%=>50%
    Tue Jul 18 12:05:20 2006sgallesPercent Complete30%=>40%
    Thu Jul 6 07:46:09 2006erkCarbon-Copy-=>Added erk

    Back to the top

    Powered by Savane 3.1-cleanup