tsp-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]