RE : [Tsp-devel] Etat du canal commande XMLRPC ?

[TSP]

Je prends le choix 1, a mon avis il sera + simple que d'attendre le fixe xml
RPC.
Surtout qu'il n'aura pas d'impacts pour ceux restés en 0.7.3
Y++

-----Original Message-----
From: Erk [mailto:address@hidden
Sent: Thursday, March 30, 2006 10:22 AM
To: address@hidden; Transport Sample Protocol development list
Subject: Re: [Tsp-devel] Etat du canal commande XMLRPC ?


Le 29/03/06, Frederik Deweerdt<address@hidden> a écrit :
> On 3/23/06, Stephane Galles <address@hidden> wrote:
> >
> > On dirait en particulier que la présence des fonctions async lui pose
> > problème à la compil. Il y a aussi une modification de la fonction
> > GLU_get_server_name
> > qui coince je crois.
> >
> Bon, j'ai jetté un coup d'oeil, voici les dégâts :) :
> - Effectivement l'api GLU a changé, du coup il n'y a plus de
> GLU_get_server_name global dispo, il faut que je voie comment
> l'appeler maintenant.

Les fonctions globales liées au GLU ont normalement été dégagée :))
Il faut récupérer l'instance du GLU que tu peux trouver dans la session

dans
void TSP_provider_request_open(const TSP_request_open_t* req_open,
                      TSP_answer_open_t* ans_open)
on a:
 glu_h = firstGLU->get_instance(...)
puis
TSP_add_session(&(ans_open->channel_id), glu_h)

qui elle-même finit par faire:

 X_session_t[X_session_nb].session_data->glu_h = glu_h;

Ensuite tu peux appeler la "fonction membre" de la structure GLU_handle_t
qui correspond:

glu_h->get_name(glu_h);

Pour les providers actifs il y a un "firstGLU" qui est le premier crée
donc (pour l'instant) on a des trucs bizarres
comme dans tsp_provider.c:
const char* TSP_provider_get_name() {
  assert(firstGLU);
  return firstGLU->get_name(firstGLU);
}

Wouala.

Pour le reste j'ai des modifs du tsp_rpc.x qui sont encore non commité
ce sont "simplement":

   - des rajouts pour les tsp_request_extended_infos
   - des modifs pour les structures async_sample_t afin
     qu'elles incluent le channel id.
Je joins le fichier pour que vous puissiez juger des changements à venir
sur le tsp_rpc.x.

Je peux (au choix):

     1) Commiter rapidement car ces modifs ne "cassent" pas le code
         actuel tant qu'elles ne sont pas utilisées.
         Cela fera 1 fonction a bouchonner en + pour Fred
         tsp_request_extended_informations.
Je pr

     2) Attendre les modifs de Fred pour commiter ensuite et mettre
         à jour XML-RPC.

Votre choix sera le mien.

--
Erk

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

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.

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