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 06 Jul 2006 07:46:08 AM UTC  
 
Category: tsp coreShould Start On: Wed 05 Jul 2006 10:00:00 PM UTC
Should be Finished on: Wed 05 Jul 2006 10:00:00 PM UTCPriority: 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 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
>/opt/tsp/lib
>/usr/local/lib
>/usr/lib
>/lib
>~/.tsp/lib
>+ LD_LIBRARY_PATH


I agree with those locations with some
others like:
/opt/tsp/plugins
$HOME/.tsp/plugins
$TSP_PLUGINS_PATH if it is defined.

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

I would suggest:

$TSP_PLUGINS_PATH
$HOME/.tsp/lib
$HOME/.tsp/plugins
/opt/tsp/plugins
/opt/tsp/lib

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) {
>dlopen(lib)
>try to dlsym(TSP_XYZ_request),
>if (sym defined)
>register_handler(TSP_XYZ_request)
>}
>}


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
liblist.add_if_unique(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
TSP_provider_rqh_manager_refresh

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 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>
Project MemberIn charge of this item.
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
/opt/tsp/lib
/usr/local/lib
/usr/lib
/lib
~/.tsp/lib
+ LD_LIBRARY_PATH

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

Frederik Deweerdt <deweerdt>
Project 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
tsp/core/ctrl_init/tsp_provider_init.c:TSP_provider_run

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 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
Wed 19 Jul 2006 07:46:42 AM UTC, comment #2:

Cool,
J'essaierais de faire un petit essai sous peu.

Eric NOULARD <erk>
Project 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

cmake -DBUILD_XMLRPC=ON .

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 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:
http://www.mail-archive.com/tsp-devel@nongnu.org/msg00321.html.

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

http://www.mail-archive.com/tsp-devel@nongnu.org/msg00321.html

> 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 20 Feb 2007 09:12:18 PM UTCsgallesPercent Complete60%=>90%
    Mon 14 Aug 2006 03:39:26 AM UTCsgallesPercent Complete50%=>60%
    Wed 19 Jul 2006 12:55:23 AM UTCsgallesPercent Complete40%=>50%
    Tue 18 Jul 2006 12:05:20 PM UTCsgallesPercent Complete30%=>40%
    Thu 06 Jul 2006 07:46:09 AM UTCerkCarbon-Copy-=>Added erk

    Back to the top


    Powered by Savane 3.1-cleanup