>> 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.

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)
 }
}

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

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.

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

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.