Re: [Tsp-devel] JTSP + URL = OK

[Stephane Galles]

Hello,

ben, non, j'ai pas d'idée précise de spec, je disais cela parceque je ne 
suis pas
un adepte des comportements laxistes. Néanmoins, je me range
à l'avis de la majorité et j'implémente ce que vous voulez coté Java.

Si je comprend bien ta réponse Eric, tu préfère que
les comportements laxistes (case insensitive, début de nom de serveur)
soient implémentés dans la lib TSP avec possibilité de l'activer
ou non, c'est ça ? Genre avec des options dans l'API et le client
choisi ce qu'il veut activer ?

Confirme moi cela, et pas de problèmes, je l'implémente.

En tous cas, merci Robert pour tes explication sur les URL, mon
but est quoi qu'il en soit de faire en sorte que la partie JAVA
ait le même comportement que la partie C

Au fait jsynoptic est en bonne voie d'utiliser les URL,
j'ai pas fait de commit mais cela marche.

(Pour conclure sur le sujet, Je veux juste modifier trés légèrement
l'exemple de Robert

Un serveur avec :

   totoNewGen:0
   toto:1
On a :
   ///toto        =>    totoNewGen:0 
   ///toto:0        =>    totoNewGen:0
   ///toto:1        =>    toto:1

Voila, je n'aime pas trop à cause de ce cas, mais je comprend
que ce comportement puisse plaire quand même dans les cas simples)

A+

Steph

NOULARD Eric wrote:

> Bah c'est pas très joli...
> Mais ce sera probablement & [malheureusement] apprécié des utilisateurs
> ce comportement laxiste :))
>
> Mon avis est que c'est à l'appli consumer finale
> (stdout, jstdout, tsp_gdisp·..) d'être tolérante
> case insensitive, match partiel etc...
>
> La request handler RPC peut lui fournir le service de recherche
> du progid "à la limite" mais pour ce qui est du nom
> ben faudrait être plus strict.
>
> Ce qui m'embête dans l'histoire c'est pas tant de
> matcher le premier provider c'est de ne pas savoir que
> j'aurais pu en terminant l'URL autrement savoir qu'il en 
> avait 2...
>
> Quoiqu'il en soit si Stephane nous propose une specs
> qui allie souplesse et strictness ben je l'accepte et je veux
> bien le coder pour C.
>
> Toutefois j'admet que la recherche "intuitive" de l'URL dépend
> du protocole donc on peut admettre que le request handler RPC
> soit plus 'tolérant' que son homologue CORBA/XML-RPC etc...
>
> Et pis autant avec un service de nommage CORBA on doit
> pouvoir découvrir TOUS les serveurs TSP autant avec RPC
> partir à la recherche de tous les serveurs existant et qui matche
> une URL donnée doit pouvoir durer un long moment??
>
> Le lun 15/11/2004 à 15:18, PAGNOT, Robert a écrit :
>  
>
> > Eh ben tant pis, si l'utilisateur ne spécifie pas un SERVERNAME complet, il
> > trouvera le premier qui correspond ...
> >
> > Par conséquent, supposons que l'on ait sur une même machine:
> >         toto:0
> >         totoNewGen:1   (car :0 est impossible car RPC_PROG_ID différents
> > !!!)
> >
> > Alors un accès URL du style ... donnera ... :
> >         ///toto         =>   toto:0
> >         ///toto:0               =>   toto:0
> >         ///toto:1               =>   totoNewGen:1
> >         ///totoNewGen   => totoNewGen:1
> >         ///totoNewGen:0 => erreur !!!
> >         ///totoNewGen:1 => totoNewGen:1
> >
> > Je n'ai pas testé ces comportements limites, le cheminement chaotique de mon
> > esprit tordu n'est pas arrivé jusque là {:o]
> >
> > Je mets notre bon Eric en copie au cas où il serait pas d'accord :-[
> >
> > A+
> >
> >         Robert
> >
> >
> >    
> >
> > > -----Original Message-----
> > > From: Stephane Galles [mailto:address@hidden
> > > Sent: Monday, November 15, 2004 3:07 PM
> > > To: PAGNOT, Robert
> > > Cc: tsp-devel
> > > Subject: Re: [Tsp-devel] JTSP + URL = OK
> > >
> > >
> > > Hello,
> > >
> > > OK. Pourquoi pas.
> > >
> > > Mais que fait - on si on a deux providers genre :
> > >
> > > toto
> > > totoNewGen
> > >
> > > pour se connecter à toto avec :///toto
> > > On risque d'embarquer totoNewGen...
> > >
> > > Ou alors il faut des wildcard.
> > >
> > > A+
> > >
> > > Steph
> > >
> > > PAGNOT, Robert wrote:
> > >
> > >      
> > >
> > > > Désolé, cela doit effectivement marcher comme ça, d'où 
> > > >        
> > > l'utilisation de
> > >      
> > >
> > > > strncmp(X,Y,strlen(X)) dans tsp_client.c. Et je devrais même 
> > > >        
> > > traiter le
> > >      
> > >
> > > > "Case sensitivity" pour prendre n'importe quoi en utilisant 
> > > >        
> > > strncasecmp ...
> > >      
> > >
> > > > C'est clair que c'est un comportement "aux limites". Je le 
> > > >        
> > > rajouterai dans
> > >      
> > >
> > > > les USAGEs des URLs.
> > > >
> > > > A+
> > > >
> > > >         Robert
> > > >
> > > >
> > > >
> > > >
> > > >        
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephane Galles [mailto:address@hidden
> > > > > Sent: Monday, November 15, 2004 2:42 PM
> > > > > To: PAGNOT, Robert
> > > > > Cc: tsp-devel
> > > > > Subject: Re: [Tsp-devel] JTSP + URL = OK
> > > > >
> > > > >
> > > > > Salut Robert,
> > > > >
> > > > > oui, je crois que j'avais bien compris le fonctionnement de l'URL,
> > > > > mais il y a quand même, à mon avis, quelque chose d'étrange
> > > > > dans l'utilisation du SERVERNAME pour la partie C.
> > > > >
> > > > > Apres avoir regardé de plus près, en fait c'est plus subtil que je
> > > > > ne pensais :
> > > > >
> > > > > Lance le StubbedServer et connecte toi sous stdout avec 
> > > > > :///StubbedServer
> > > > > Cela marche. C'est normal
> > > > >
> > > > > Lance le StubbedServer et connecte toi sous stdout avec 
> > > > >          
> > > :///blablabla
> > >      
> > >
> > > > > Cela ne marche pas. C'est normal
> > > > >
> > > > > Lance le StubbedServer et connecte toi sous stdout avec :///Stu
> > > > > Cela marche ! CE N'EST PAS NORMAL (du moins je ne crois
> > > > > pas ou alors il faut documenter ce comportement).
> > > > >
> > > > > A+
> > > > >
> > > > > Steph
> > > > >
> > > > >
> > > > > PAGNOT, Robert wrote:
> > > > >
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > Salut Stéph,
> > > > > >
> > > > > > Le principe de l'utilisation de l'URL (tu peux les voir 
> > > > > >     
> > > > > >
> > > > > >            
> > > > > d'ailleurs dans les
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > help des consumers C) consiste à :
> > > > > >         <rpc://hostname> => trouve le premier provider existant sur
> > > > > > "hostname", soit un fonctionnement identique à la pré-histoire.
> > > > > >
> > > > > >         + </servername:port> permet de préciser un peu plus à qui l'on
> > > > > > s'adresse, en cas de multi-providers. Pour info, avec Yves, 
> > > > > >     
> > > > > >
> > > > > >            
> > > > > on travaille sur
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > la même machine avec des providers différents, et chacun se 
> > > > > >     
> > > > > >
> > > > > >            
> > > > > connecte avec
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > une URL du type <///myServerName> et ça marche !!!
> > > > > >
> > > > > >         Par conséquent, on tient compte du SERVERNAME, lorsqu'il est
> > > > > > explicité. Le pb, est qu'avec RPC, on doit établir une connection
> > > > > > (clnt_create) pour connaître le nom de celui qui est au bout 
> > > > > >     
> > > > > >
> > > > > >            
> > > > > du fil ...
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > >         On pourrait s'amuser à créer une table de hash pour
> > > > > > SERVERNAME:PORTNUM et utiliser l'ID sortant du hachage comme 
> > > > > >     
> > > > > >
> > > > > >            
> > > > > RPC_PROG_ID ?
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > Cela éviterai les tentatives de connection ...
> > > > > >
> > > > > > A+
> > > > > >
> > > > > > Robert PAGNOT
> > > > > > ASTRIUM SAS
> > > > > > AEA56 - Ground Systems
> > > > > > tél.: 05 62 19 55 32 
> > > > > > fax.: 05 62 19 77 41 
> > > > > > <mailto:address@hidden>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >     
> > > > > >
> > > > > >            
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stephane Galles [mailto:address@hidden
> > > > > > > Sent: Sunday, November 14, 2004 10:15 PM
> > > > > > > To: tsp-devel
> > > > > > > Subject: [Tsp-devel] JTSP + URL = OK
> > > > > > >
> > > > > > >
> > > > > > > Bonjour,
> > > > > > >
> > > > > > > les URL fonctionnent maintenant avec JTSP.
> > > > > > >
> > > > > > > Lancez ant sans arguments dans DEVBASE, et les 
> > > > > > >              
> > > explications suivront
> > >      
> > >
> > > > > > > En fait jsynoptic et jstdout fonctionnent, mais seul 
> > > > > > >              
> > > jstdout utilise
> > >      
> > >
> > > > > > > réellement les URL. jsynoptic continue de séparer les valeurs 
> > > > > > > dans son GUI.
> > > > > > > Je n'ai pas regardé en détail comment était fait jsynoptic, 
> > > > > > > mais si le code
> > > > > > > du GUI est dans le plugin, ai - je l'autorisation de modifier 
> > > > > > > le GUI pour
> > > > > > > faire saisir une URL, et non plus des valeurs éclatée ? (je 
> > > > > > > ne sais pas si
> > > > > > > c'est possible en fait, je ne sais pas comment est découpé le code
> > > > > > > jsynoptic-plugin et jsynoptic-code)
> > > > > > >
> > > > > > > Sinon, en fait, sans vouloir cafter, j'ai même l'impression 
> > > > > > > que les URL
> > > > > > > fonctionnent maintenant mieux avec JTSP qu'avec TSP, vu 
> > > > > > >              
> > > qu'on dirait
> > >      
> > >
> > > > > > > bien que le grand frêre C ne tient pas compte du 
> > > > > > >              
> > > SERVERNAME pour la 
> > >      
> > >
> > > > > > > recherche
> > > > > > > du provider...
> > > > > > >
> > > > > > > J'dis ça, j'dis rien  ;)
> > > > > > >
> > > > > > > Steph.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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.
> > > > >   
> > > > >
> > > > >          
> > > > >
> > > > > > > ---------------------------------------------------------
> > > > > > >  
> > > > > > >
> > > > > > >       
> > > > > > >
> > > > > > >              
> > > > > ------------------------------------------------------------
> > > > >          
> > > ------------
> > >      
> > >
> > > > > ---------------------------------------------------------
> > > > >
> > > > > 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.
> > >      
> > >
> > > > > ---------------------------------------------------------
> > > > >   
> > > > >
> > > > >