[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tsp-devel] [LONG] Cohabitation xmlrpc - rpc
From: |
Frederik Deweerdt |
Subject: |
[Tsp-devel] [LONG] Cohabitation xmlrpc - rpc |
Date: |
Sat, 20 Aug 2005 01:34:34 +0200 |
User-agent: |
Mutt/1.5.6i |
Kaixo[1] liste,
Aujourd'hui il n'est pas possible de faire cohabiter dans le même executable
TSP un canal commandes rpc et un canal commandes xmlrpc. C'est du au fait
que tsp_consummer.c utilise l'API de tsp_client.c avec TSP_remote_open_server,
TSP_remote_close_server notamment (liste complete plus bas). Ces deux
fonctions,
entre autres, étant présentes dans xmlrpc/tsp_client.c et rpc/tsp_client.c,
on ne peut pas linker un même client (client_stdout.c par exemple) avec les
deux "librairies" en même temps.
Pour pallier à cela, on choisit actuellement _à la compilation_ le transport
à utiliser, rpc par défaut et --enable-xmlrpc compile pour... bon, vous avez
compris :)
Le but, afin de se raprocher de la domination mondiale, serait de pouvoir
choisir
le transport en fonction du protocole que passe l'utilisateur à la ligne de
commande
ou a son appli GTK 3.0 ;). Pour cela je me propose:
- de refaire le code de parsing URL, pour être compatible std66 alias rfc 3986
sur les URI (Dans la version que j'ai écrite actuellement, j'utilise les regexp
POSIX, y a-t-il une contre-indication à ce sujet sur les plate-formes
vénérables
que nous supportons?). Les nouvelles URLs auraient la forme suivante:
protocole://hostname[:port]/server_name#server_instance
- d'introduire une structure du type :
TSP_client_operations rpc_client_ops = {
.TSP_provider_information = TSP_provider_information,
.TSP_remote_open_server = TSP_remote_open_server,
.TSP_remote_close_server = TSP_remote_close_server,
.TSP_get_server_max_number = TSP_get_server_max_number,
.TSP_request_open = TSP_request_open,
.TSP_request_close = TSP_request_close,
.TSP_request_information = TSP_request_information,
.TSP_request_sample = TSP_request_sample,
.TSP_request_sample_init = TSP_request_sample_init,
.TSP_request_sample_destroy = TSP_request_sample_destroy,
.TSP_protocol = TSP_protocol,
};
Rassemblant les pointeurs de fonction de l'API cliente
/!\ Question, les initialiseurs de struct de ce type sont compatibles avec tous
les
compilateurs que l'on utilise?
- d'ajouter un tableau global du genre
TSP_client_operations available_transports[] = {
#ifdef RPC_TRANSPORT
rpc_client_ops,
#endif
#ifdef XMLRPC_TRANSPORT
xmlrpc_client_ops,
#endif
NULL
}
Ce tableau serait parcouru par le TSP_connect_url qui trouverait le bon
transport en appelant xxx_client_ops.TSP_protocol() et en le comparant
au protocole de l'URL
Voilà, je suis preneur de toute idée/suggestion/bière :)
A+
Fred
[1] Le basque étant en passe de rejoindre le français comme langue de
communication des développeurs TSP, je me mets au goût du jour
RE : [Tsp-devel] Sondage: utilisation d'Ant et Eclipse, eric.noulard, 2005/08/18