RE : [Tsp-devel] [LONG] Cohabitation xmlrpc - rpc

[PAGNOT, Robert]

Salut à toi, ô communau-TSP-é

Etant un peu à l'origine de la connexion par URL interposée, je me dois de
vous écrire un petit mot à ce sujet.

PREMIEREMENT : le format URL initial a été "inventé" de toutes pièces selon
le besoin (host + protocole + nom du serveur + numéro du serveur) - donc
s'il existe une RFC là-dessus, APPLIQUEZ-LA. Je n'en pleurerai pas ....

DEUXIEMENT : l'implementation C du decodage de l'URL a été bricolée au plus
vite pour que cela marche. Certes, "au plus vite" avec votre serviteur ne
signifie pas "au plus simple", ni, (surtout NI) "au plus compréhensible". Je
ne connais pas les fonctions regexp POSIX, donc si cela peut simplifier le
décodage, GO AHEAD. Mais attention à VxWorks qui n'a pas grand chose à
proposer en POSIX, même si, à priori, VxWorks ne tournera pas un consumer
TSP (enfin, on sait jamais ... des esprits tordus pourraient vouloir y coder
une sorte de groupeur-routeur de samples TSP). K

TROISIEMENT : TSP consumer lib = KISS

A+

        TSP-ô-Bob

-----Original Message-----
From: Frederik Deweerdt [mailto:address@hidden
Sent: Saturday, August 20, 2005 1:35 AM
To: Devel TSP
Subject: [Tsp-devel] [LONG] Cohabitation xmlrpc - rpc


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


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

---------------------------------------------------------

CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT 
ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.

SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, 
MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER 
ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, 
VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE 
COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.



This email is for information only and will not bind EADS Astrium SAS in any 
contract or obligation, nor its subsidiaries.

If you have received it in error, please notify the sender by return email. If 
you are not the addressee of this email, you must not use, keep, disseminate, 
copy, print or otherwise deal with it.

---------------------------------------------------------