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


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

task #5703: Implement XML-RPC command channel

Submitter:  Eric NOULARD <erk>
Submitted:  Thu 06 Jul 2006 07:46:08 AM UTC
Category:  tsp core Should Start On:  Wed 05 Jul 2006 10:00:00 PM UTC
Should be Finished on:  Wed 05 Jul 2006 10:00:00 PM UTC Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  sgalles Percent Complete:  90%
Open/Closed:  Open Effort:  0.00

Jump to the original submission

Wed 28 Feb 2007 09:12:45 AM UTC, 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>
Group administrator
Tue 27 Feb 2007 01:36:08 AM UTC, 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>
Group Member
Mon 26 Feb 2007 10:33:18 PM UTC, 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>
Group administrator
Mon 26 Feb 2007 09:55:52 PM UTC, 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>
Group administrator
Mon 26 Feb 2007 07:35:20 PM UTC, 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>
Group Member
Tue 20 Feb 2007 09:12:19 PM UTC, 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>
Group Member
Mon 14 Aug 2006 03:39:26 AM UTC, 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>
Group Member
Wed 19 Jul 2006 11:32:32 AM UTC, 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>
Group Member
Wed 19 Jul 2006 07:46:42 AM UTC, comment #2: 

J'essaierais de faire un petit essai sous peu.

Eric NOULARD <erk>
Group administrator
Wed 19 Jul 2006 12:55:23 AM UTC, 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>
Group Member
Thu 06 Jul 2006 07:46:08 AM UTC, 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>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-02-20 sgalles Percent Complete60% 90%
    2006-08-14 sgalles Percent Complete50% 60%
    2006-07-19 sgalles Percent Complete40% 50%
    2006-07-18 sgalles Percent Complete30% 40%
    2006-07-06 erk Carbon-Copy- Added erk

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code