Accueil -|- Visuel -|- Logistique -|- Applications réparties
| La pseudo-archive
Java est un service proposé par la SARL diaam informatique,
et il est hébergé par la
Sogid.
|
 |
| Pseudo-Archive Java : Accueil -|- Visuel -|- Logistique -|- Applications réparties |
|
||
|
|||
From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: java@u-strasbg.fr Subject: RMI et interface Date sent: Mon, 21 May 2001 15:30:11 +0200 Send reply to: java@u-strasbg.fr Bonjour, j'aimerais avoir un avis d'expert sur le cas suivant Je désire mettre en place un architecture d'objets distribués : - un serveur - des clients très légers Le serveur et les clients sont en Java et n'ont pas de raison d'être dans un autre langage. J'ai donc opté, a priori, pour une architecture RMI. J'étudie la possibilité que le client soit si léger, qu'il ne connaisse même pas son interface. J'envisage donc, que le serveur lui fournisse les classes d'interface. L'interface sera du swing. Le JRE sera au moins 1.2.2 (il est possible d'imposer le même JRE sur le client et le serveur). Est-il possible de faire passer du SWING et des classes dérivées (et donc non connue du client) à travers SWING ? J'opterais pour non, car des classes dérivées de SWING ne peuvent pas dérivées aussi de java.rmi.server.UnicastRemoteObject. Faut-il implémenter un classloader pour aller chercher les classes dérivant de SWING sur le serveur ? J'opterais pour oui. Est-ce compliquer d'écrire un classloader qui aille lire les classes disponible sur le serveur depuis le client (avec les problème de recouvrement possible des classes déclarées simultanément sur le serveur et le client (toutes les classes natives du JRE à priori)) ? Je suis dans l'expectative :-) De façon général, que pensez-vous de cette approche ? Merci -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr
From: Thierry Janaudy <tjanaudy@voxgeneration.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Mon, 21 May 2001 18:23:03 +0100 Send reply to: java@u-strasbg.fr Inline. =>-----Original Message----- =>From: Erik Mazoyer [mailto:erik.mazoyer@hyperoffice.fr] =>Sent: 21 May 2001 14:30 =>To: java@u-strasbg.fr =>Subject: RMI et interface => => =>Bonjour, Salut, => =>j'aimerais avoir un avis d'expert sur le cas suivant Je ne me considere pas comme expert, mais on va essayer. => =>Je désire mettre en place un architecture d'objets distribués : =>- un serveur =>- des clients très légers C'est la mode. => =>Le serveur et les clients sont en Java et n'ont pas de raison =>d'être dans un =>autre langage. =>J'ai donc opté, a priori, pour une architecture RMI. Premier probleme: On ne peut pas parler de client leger avec du Swing cote client. Le client leger c'est le navigateur avec HTML ou le portable avec WML. Une applet Java ou un client Swing, c'est pas leger. Mes questions sont: - Est-ce une appli Internet? - Est-ce une appli Intranet? - Est-ce les deux? - Les fonctionnalites de ton client obligent-elles a avoir une IHM aussi complexe que Swing? - Ne peux-tu pas opter pour un client HTML <-> JSP/Servlet <-> Whatever ? - Pourquoi Swing? Recois-tu des flux d'info "temps reel" ? ...etc? - Pourquoi RMI? HTTP? Problemes de Firewall? => =>J'étudie la possibilité que le client soit si léger, qu'il ne =>connaisse même =>pas son interface. =>J'envisage donc, que le serveur lui fournisse les classes d'interface. Trop complique. Je suis partisant du principe de l'armee americaine: KISS (Keep It Simple Stupid) :-) Laisse tomber le ClassLoader. Les composants Swing implementent Serializable, mais je deconseille de faire cela et de construire ton IHM comme cela... *fortement* deconseille. Je ne met pas la suite de l'email. Reponds d'abord aux questions ci-dessus, on verra apres, ok? =>De façon général, que pensez-vous de cette approche ? => =>Merci Thierry => =>-------------------------------------------------------------------- =>Erik Mazoyer, Chef de projet =>HyperOffice =>6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex =>Tél. 01 41 96 96 76 =>Fax 01 41 96 96 77 =>Mél erik.mazoyer@hyperoffice.fr => ************************************************************@~|!+ This email and any attachments are confidential and are intended for the addressee(s) only. If you are not the intended recipient, please notify the sender immediately by reply email and then delete it from your system. Any disclosure, forwarding or copying of this email or its attachments is expressly prohibited. ************************************************************@~|!+
From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Mon, 21 May 2001 19:41:10 +0200 Send reply to: java@u-strasbg.fr =>Le serveur et les clients sont en Java et n'ont pas de raison =>d'être dans un =>autre langage. =>J'ai donc opté, a priori, pour une architecture RMI. >Premier probleme: On ne peut pas parler de client leger avec du Swing >cote client. Le client leger c'est le navigateur avec HTML ou le portable >avec WML. Une applet Java ou un client Swing, c'est pas leger. Par client léger, j'entends un client Java (non pas un browser) qui ne soit définit que par les classes natives du JRE plus un ensemble très réduit de classes définies par mes soins. Mes questions sont: > Est-ce une appli Internet? > Est-ce une appli Intranet? Intranet uniquement > Les fonctionnalites de ton client obligent-elles a avoir une IHM > aussi complexe que Swing? Oui, impératif > Ne peux-tu pas opter pour un client HTML <-> JSP/Servlet <-> Whatever ? J'ai déjà implementé ce genre de solution sur d'autres projets(HTML <-> Servlet+XML+XSL <-> Moteur Java <-> Oracle). Ici c'est Swing :-) > Pourquoi Swing? Recois-tu des flux d'info "temps reel" ? ...etc? Pour des raisons d'interface complexe fenétrée. > Pourquoi RMI? HTTP? Problemes de Firewall? Je ne vois pas bien le rapport. J'ai besoin d'objets distribués et plutot que de tout écrire je me dirige vers une solution "simple". Je pense choisir RMI plutot que Corba pour la simplicité (que je peux utiliser étant java<=>java). > Trop complique. Je suis partisant du principe de l'armee americaine: > KISS (Keep It Simple Stupid) :-) Laisse tomber le ClassLoader. Les > composants Swing implementent Serializable, Oui, mais pour deserializer une instance il faut que la classe soit connue hors ce n'est pas le cas. Si je défini ma classe "MaFrame" qui dérive de JFrame, mon client léger connaitra "JFrame" mais pas "MaFrame". Il ne pourra donc pas déserializer ma classe "MaFrame". Et je ne suis pas capable de donner "MaFrame" à mon client, car quand le client est compilé, "MaFrame" n'existe pas encore. > Je ne met pas la suite de l'email. Reponds d'abord aux questions > ci-dessus, on verra apres, ok? OK A+ -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr
Send reply to: "Chris Ravenscroft" <Chris.Ravenscroft@alcatel.com> From: "Chris Ravenscroft" <Chris.Ravenscroft@ind.alcatel.com> To: <java@u-strasbg.fr> Subject: Re: RMI et interface Date sent: Mon, 21 May 2001 11:59:27 -0700 Well, j'adhere aux commentaires de mon camarade Thierry Janaudy. D'autant que c'est des clients TRES legers. Dans ce cas on met rarement en place des solutions qui requierent la moindre installation. Typiquement, les JSP me semblent la solution de choix ici : les clients reposent sur un web browser, point barre. Et ca reste du Java. Concernant l'idee de faire passer du Swing dans le tuyau (le client ne connait pas son interface), est-ce fait pour travailler sur une liaison haut debit ? Classes derivees : Serializable. De facon generale, j'ai l'impression que tu veux re-inventer la roue. -C ................................................................... -Chris Ravenscroft Principal Software Engineer, Alcatel NMS - Calabasas / (818) 878-5094 ----- Original Message ----- From: "Erik Mazoyer" <erik.mazoyer@hyperoffice.fr> To: <java@u-strasbg.fr> Sent: Monday, May 21, 2001 6:30 AM Subject: RMI et interface Bonjour, j'aimerais avoir un avis d'expert sur le cas suivant Je désire mettre en place un architecture d'objets distribués : - un serveur - des clients très légers Le serveur et les clients sont en Java et n'ont pas de raison d'être dans un autre langage. J'ai donc opté, a priori, pour une architecture RMI. J'étudie la possibilité que le client soit si léger, qu'il ne connaisse même pas son interface. J'envisage donc, que le serveur lui fournisse les classes d'interface. L'interface sera du swing. Le JRE sera au moins 1.2.2 (il est possible d'imposer le même JRE sur le client et le serveur). Est-il possible de faire passer du SWING et des classes dérivées (et donc non connue du client) à travers SWING ? J'opterais pour non, car des classes dérivées de SWING ne peuvent pas dérivées aussi de java.rmi.server.UnicastRemoteObject. Faut-il implémenter un classloader pour aller chercher les classes dérivant de SWING sur le serveur ? J'opterais pour oui. Est-ce compliquer d'écrire un classloader qui aille lire les classes disponible sur le serveur depuis le client (avec les problème de recouvrement possible des classes déclarées simultanément sur le serveur et le client (toutes les classes natives du JRE à priori)) ? Je suis dans l'expectative :-) De façon général, que pensez-vous de cette approche ? Merci -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr
From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: java@u-strasbg.fr Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 08:49:53 +0200 Send reply to: java@u-strasbg.fr Je suis convaincu par la solution HTML et Servlet. Par contre elle ne permet pas de tout faire. Ici la solution HTML n'est pas envisageable. Dans ce contexte, j'ai besoin d'un client swing qui dialogue avec un serveur. Je me suis donc tout naturellement dirigé vers RMI. Mais en creusant l'architecture, je me suis aperçu, que si je pouvais faire placer l'interface sur le serveur (comme un serveur Web) j'y trouverais de nombreux avantages. Mon client ne connaitrait que le minimum nécessaire pour dialoguer avec le serveur. Je compte écrire : monServeur = (MonServeur)Naming.lookup(//toto/monServeur"); JFrame mainFrame = monServeur.getMainFrame(); mainFrame.pack(); mainFrame.show(); Cela permet de modifier l'interface de l'application sans devoir réintaller l'application cliente. Mon contexte réseau est ethernet 100Mb/s. Je peux donc envisager, a priori, ce genre d'architecture sans problème. En fait cela ressemble au HTTP, le serveur décrivant la page à afficher. Dans ce contexte, mes questions sont : 1) Quelqu'un a t'il tenté cette approche ? 2) Est-il possible de faire passer du SWING et des classes dérivées (et donc non connue du client) à travers SWING ? 3) Faut-il implémenter un classloader pour aller chercher les classes dérivant de SWING sur le serveur ? 4) Est-ce compliquer d'écrire un classloader qui aille lire les classes disponible sur le serveur depuis le client (avec les problème de recouvrement possible des classes déclarées simultanément sur le serveur et le client (toutes les classes natives du JRE à priori)) ? -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr -----Message d'origine----- De: Chris Ravenscroft [mailto:Chris.Ravenscroft@ind.alcatel.com] Date: lundi 21 mai 2001 20:59 À: java@u-strasbg.fr Objet: Re: RMI et interface Well, j'adhere aux commentaires de mon camarade Thierry Janaudy. D'autant que c'est des clients TRES legers. Dans ce cas on met rarement en place des solutions qui requierent la moindre installation. Typiquement, les JSP me semblent la solution de choix ici : les clients reposent sur un web browser, point barre. Et ca reste du Java. Concernant l'idee de faire passer du Swing dans le tuyau (le client ne connait pas son interface), est-ce fait pour travailler sur une liaison haut debit ? Classes derivees : Serializable. De facon generale, j'ai l'impression que tu veux re-inventer la roue. -C ................................................................... -Chris Ravenscroft Principal Software Engineer, Alcatel NMS - Calabasas / (818) 878-5094 ----- Original Message ----- From: "Erik Mazoyer" <erik.mazoyer@hyperoffice.fr> To: <java@u-strasbg.fr> Sent: Monday, May 21, 2001 6:30 AM Subject: RMI et interface Bonjour, j'aimerais avoir un avis d'expert sur le cas suivant Je désire mettre en place un architecture d'objets distribués : - un serveur - des clients très légers Le serveur et les clients sont en Java et n'ont pas de raison d'être dans un autre langage. J'ai donc opté, a priori, pour une architecture RMI. J'étudie la possibilité que le client soit si léger, qu'il ne connaisse même pas son interface. J'envisage donc, que le serveur lui fournisse les classes d'interface. L'interface sera du swing. Le JRE sera au moins 1.2.2 (il est possible d'imposer le même JRE sur le client et le serveur). Est-il possible de faire passer du SWING et des classes dérivées (et donc non connue du client) à travers SWING ? J'opterais pour non, car des classes dérivées de SWING ne peuvent pas dérivées aussi de java.rmi.server.UnicastRemoteObject. Faut-il implémenter un classloader pour aller chercher les classes dérivant de SWING sur le serveur ? J'opterais pour oui. Est-ce compliquer d'écrire un classloader qui aille lire les classes disponible sur le serveur depuis le client (avec les problème de recouvrement possible des classes déclarées simultanément sur le serveur et le client (toutes les classes natives du JRE à priori)) ? Je suis dans l'expectative :-) De façon général, que pensez-vous de cette approche ? Merci -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr
From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: java@u-strasbg.fr Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 10:10:29 +0200 Send reply to: java@u-strasbg.fr Bonjour Guillaume > Le principal problème des écrans HTML est leur pauvreté au niveau interface > graphique et possibilités d'impression. > Si l'on veut faire des applications vraiment ergonomiques avec des > possibilités graphiques, il va falloir jouer avec le HTML dynamique (bonjour > la compatibilité des browsers), rajouter des applets...etc. Je partage tout à fait ton avis. Je me "bat" souvent avec mes clients et mes graphistes pour créer des sites le plus possible compatible HTML 3. Et de n'inclure Javascript, HTML dynamique, applets, etc, que dans les cas vraiment importants. Et le coût de la page monte vite en flèche (test sous Mac/PC/unix x IE3, IE4 IE5, N3, N4, N6 = 18 plateformes). Et pour l'instant on ne prend pas en compte Opera :-) > La mode actuelle veut que les applications Web passent forcément par du > HTML. On a donc banni les client/serveur d'antan qui présentaient > pourtant des clients évolués au niveau GUI pour des raisons de > déploiement. Il reviennent :-) Corba, RMI,... sont directement issus de ces "client/serveur d'antan". On a juste pris un chemin un peu long :-) > Donc si ton problème est de déploiement d'applications Java, je suis sûr > qu'Olivier D. va te trouver une URL d'enfer sur Pharos pour t'aider dans tes > recherches! ;-)). En plus passer du Swing dans RMI, heu... En fait, c'est juste le compiler que je désire faire passer. Le serveur construisant l'interface (avec le moteur d'interrogation) pour le client. En gros : Le client : "Cher serveur, que dois je afficher à l'utilisateur pour lui donner accès à xxxx" Le serveur : "Mon cher client utilisez la classe MaFrame pour l'interface. Vous la trouverez ici" Le client : "Merci" > je pense que tu risques de rencontrer des problèmes! C'est ce que je cherche à évaluer. Quelqu'un a t'il déjà tenté cette expérience ? Je vais faire une maquette simple pour tester. Je vous ferais part des résultats. > Voila c'était mes 2 euros cents sur le sujet... Merci Cordialement, -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr -----Message d'origine----- De: Guillaume Helle [mailto:ghelle@capgemini.fr] Date: mardi 22 mai 2001 10:40 À: java@u-strasbg.fr Objet: Re: RMI et interface Bonjour, je me permet de m'immiscer dans la conversation pour faire part de ma longue expérience sur les applications Web...;-) D'abord je n'aime pas le terme "client léger" lorsque l'on parle d'un browser...surtout IE. Il n'y a qu'à voir les ressources qu'il utilise pour se rendre compte qu'il n'est pas plus léger qu'une JVM. Le principal problème des écrans HTML est leur pauvreté au niveau interface graphique et possibilités d'impression. Si l'on veut faire des applications vraiment ergonomiques avec des possibilités graphiques, il va falloir jouer avec le HTML dynamique (bonjour la compatibilité des browsers), rajouter des applets...etc. De plus les impressions ne sortent souvent pas le même résultat en fonction du browser et tout ce qui passe à droite de l'écran, pourtant accessible via l'ascenseur, est tronqué. On est donc souvent obligé d'utiliser des outils de Report pour générer du PDF imprimable ou de se torturer pour dessiner les écrans HTML (Ex.: pas de tables avec un nombre de colonnes dynamiques). La mode actuelle veut que les applications Web passent forcément par du HTML. On a donc banni les client/serveur d'antan qui présentaient pourtant des clients évolués au niveau GUI pour des raisons de déploiement. Il faut bien se rendre compte que tout cela à changé. Maintenant on peut très bien déployer des applications Java via le Web et les mettre à jour de façon automatique et transparente pour l'utilisateur. Webstart de SUN (gratos) en est un des exemples. On peut donc avoir des clients dignes de ce nom avec une véritable interface graphique ergonomique qui ne pose pas de problème de déploiement. Côté impression je reconnais qu'imprimer en Java demande encore bien des efforts au niveau développement et que l'on préfère passer encore par des reports (ne serait-ce que pour garder des traces des écrans et des états). Par contre on trouve ce genre d'outils en Java (Elixir, Cocoon,...) ce qui permet de garder une certaine homogénéité dans la solution (100% Java). Donc si ton problème est de déploiement d'applications Java, je suis sûr qu'Olivier D. va te trouver une URL d'enfer sur Pharos pour t'aider dans tes recherches! ;-)). En plus passer du Swing dans RMI, heu... je pense que tu risques de rencontrer des problèmes! Si tu as choisis Swing comme interface graphique, cela me semble correct et côté performances, hormis le lancement de la JVM qui est toujours long, avec les PC actuels (même vieux de qqs années) cela ne pose pas de problèmes. En conclusion le choix HTML/Java se pose en fonction des besoins d'interface de l'application mais on peut facilement proposer l'un ou l'autre. Le problème vient souvent de l'utilisateur qui veut une application Web dans son navigateur préféré... C'est lui qu'il faut convaincre (et souvent aussi les responsables informatique) et ce n'est pas toujours évident. Voila c'était mes 2 euros cents sur le sujet... Amicalement, Guillaume Helle CAP GEMINI ERNST & YOUNG Division SUD-OUEST 05.61.31.54.19 ghelle@capgemini.fr
Send reply to: "Guillaume Helle" <ghelle@capgemini.fr> From: "Guillaume Helle" <ghelle@capgemini.fr> To: <java@u-strasbg.fr> Subject: Re: RMI et interface Date sent: Tue, 22 May 2001 09:39:41 +0100 Organization: Cap Gemini Bonjour, je me permet de m'immiscer dans la conversation pour faire part de ma longue expérience sur les applications Web...;-) D'abord je n'aime pas le terme "client léger" lorsque l'on parle d'un browser...surtout IE. Il n'y a qu'à voir les ressources qu'il utilise pour se rendre compte qu'il n'est pas plus léger qu'une JVM. Le principal problème des écrans HTML est leur pauvreté au niveau interface graphique et possibilités d'impression. Si l'on veut faire des applications vraiment ergonomiques avec des possibilités graphiques, il va falloir jouer avec le HTML dynamique (bonjour la compatibilité des browsers), rajouter des applets...etc. De plus les impressions ne sortent souvent pas le même résultat en fonction du browser et tout ce qui passe à droite de l'écran, pourtant accessible via l'ascenseur, est tronqué. On est donc souvent obligé d'utiliser des outils de Report pour générer du PDF imprimable ou de se torturer pour dessiner les écrans HTML (Ex.: pas de tables avec un nombre de colonnes dynamiques). La mode actuelle veut que les applications Web passent forcément par du HTML. On a donc banni les client/serveur d'antan qui présentaient pourtant des clients évolués au niveau GUI pour des raisons de déploiement. Il faut bien se rendre compte que tout cela à changé. Maintenant on peut très bien déployer des applications Java via le Web et les mettre à jour de façon automatique et transparente pour l'utilisateur. Webstart de SUN (gratos) en est un des exemples. On peut donc avoir des clients dignes de ce nom avec une véritable interface graphique ergonomique qui ne pose pas de problème de déploiement. Côté impression je reconnais qu'imprimer en Java demande encore bien des efforts au niveau développement et que l'on préfère passer encore par des reports (ne serait-ce que pour garder des traces des écrans et des états). Par contre on trouve ce genre d'outils en Java (Elixir, Cocoon,...) ce qui permet de garder une certaine homogénéité dans la solution (100% Java). Donc si ton problème est de déploiement d'applications Java, je suis sûr qu'Olivier D. va te trouver une URL d'enfer sur Pharos pour t'aider dans tes recherches! ;-)). En plus passer du Swing dans RMI, heu... je pense que tu risques de rencontrer des problèmes! Si tu as choisis Swing comme interface graphique, cela me semble correct et côté performances, hormis le lancement de la JVM qui est toujours long, avec les PC actuels (même vieux de qqs années) cela ne pose pas de problèmes. En conclusion le choix HTML/Java se pose en fonction des besoins d'interface de l'application mais on peut facilement proposer l'un ou l'autre. Le problème vient souvent de l'utilisateur qui veut une application Web dans son navigateur préféré... C'est lui qu'il faut convaincre (et souvent aussi les responsables informatique) et ce n'est pas toujours évident. Voila c'était mes 2 euros cents sur le sujet... Amicalement, Guillaume Helle CAP GEMINI ERNST & YOUNG Division SUD-OUEST 05.61.31.54.19 ghelle@capgemini.fr
To: java@u-strasbg.fr Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 10:42:07 +0200 (MEST) From: Nicolas Delsaux <nicolas.delsaux@free.fr> Send reply to: java@u-strasbg.fr En réponse à Erik Mazoyer <erik.mazoyer@hyperoffice.fr>: Salut, je vais juste répondre à une partie de ta question, celle concernant le ClassLoader. > 3) Faut-il implémenter un classloader pour aller chercher les classes > dérivant de SWING sur le serveur ? Peut-être que oui, effectivement, vu que tu souhaites aller chercher des classes ailleurs que dans ton espace local... > > 4) Est-ce compliquer d'écrire un classloader qui aille lire les classes > disponible sur le serveur depuis le client (avec les problème de > recouvrement possible des classes déclarées simultanément sur le serveur > et > le client (toutes les classes natives du JRE à priori)) ? Non. Non ce n'est pas compliqué, et non il n'y a pas de risque d'erreur de recouvrement. Depuis Java 2, la méthode préconisée pour surcharger le ClassLoader consiste justement à modifier le lieu, et éventuellement l'ordre, de recherche des classes chargées, grâce à la méthode findClass. En conséquence, tu as seulement à surcharger cette méthode pouyr que les classes soient recherchées dans un espace de référence si elles correspondent à une certaine convention de nommage (par exemple org.mesclasses.amoi). Tes histoires de recouvrement ne risquent donc pas d'arriver, sauf pour ta classe d'uinterface, pour laquelle j'ai justement une question. Les protocoles d'objets distribués, comme CORBA et RMI, permettent de voir des objets distants de manière transparente. Par conséquent, tu vas créer sur ton serveur une classe Frame qui sera activée par tes clients, pas vrai ? Dans ce cas-là, ce qui se passe dans cette classe, même si ça implique un traffic réseau énorme, ne regarde pas le clie! nt, tu as donc toute liberté pour inclure toutes les classes que tu veux. Est-ce que je me trompe ? > > -------------------------------------------------------------------- > Erik Mazoyer, Chef de projet > HyperOffice > 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex > Tél. 01 41 96 96 76 > Fax 01 41 96 96 77 > Mél erik.mazoyer@hyperoffice.fr Nicolas Delsaux PS : concernant les ClassLoaders, tu peux regarder sur la pseudo-archive, ou sur le java-channel, ou sur le site d'Olivier Dedieu, qui fournit il me semble un assez bon exemple de ClassLaoder à CLASSPATH extensible.
From: Thierry Janaudy <tjanaudy@voxgeneration.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 09:44:26 +0100 Send reply to: java@u-strasbg.fr Re, =>-----Original Message----- =>From: Erik Mazoyer [mailto:erik.mazoyer@hyperoffice.fr] =>Par client léger, j'entends un client Java (non pas un =>browser) qui ne soit =>définit que par les classes natives du JRE plus un ensemble =>très réduit de =>classes définies par mes soins. Ce n'est pas ma definition d'un client "leger". =>Intranet uniquement => =>> Les fonctionnalites de ton client obligent-elles a avoir une IHM =>> aussi complexe que Swing? (...) =>Pour des raisons d'interface complexe fenétrée. =>Oui, impératif Peux-tu les decrire ces fonctionnalites? Je serais curieux de les connaitre pour savoir pourquoi Swing est obligatoire. Si je suis convaincu, on parlera des possibilites que perso je prefere en Intranet (Java Web Start, ....) => =>> Pourquoi RMI? HTTP? Problemes de Firewall? =>Je ne vois pas bien le rapport. =>J'ai besoin d'objets distribués et plutot que de tout écrire =>je me dirige =>vers une solution "simple". =>Je pense choisir RMI plutot que Corba pour la simplicité (que je peux =>utiliser étant java<=>java). La ok, RMI/JRMP si il y a du Java des deux cotes. => => =>> Trop complique. Je suis partisant du principe de l'armee =>americaine: KISS =>> (Keep It Simple Stupid) :-) =>> Laisse tomber le ClassLoader. Les composants Swing implementent =>> Serializable, => =>Oui, mais pour deserializer une instance il faut que la =>classe soit connue =>hors ce n'est pas le cas. =>Si je défini ma classe "MaFrame" qui dérive de JFrame, mon =>client léger =>connaitra "JFrame" mais pas "MaFrame". =>Il ne pourra donc pas déserializer ma classe "MaFrame". =>Et je ne suis pas capable de donner "MaFrame" à mon client, =>car quand le =>client est compilé, "MaFrame" n'existe pas encore. Sachant que j'attends la reponse concernant Swing :-), je te donne tout de meme ce vers quoi tu devrais aller IMHO: Java Web Start: Tres utile pour un client lourd comme le tien, gere les versions, et parfaitement viable dans un Intranet. http://java.sun.com/products/javawebstart/index.html RMI (JDK 1.3) avec les Objets activable. http://java.sun.com/j2se/1.3/docs/guide/rmi/activation.html -- Thierry ************************************************************@~|!+ This email and any attachments are confidential and are intended for the addressee(s) only. If you are not the intended recipient, please notify the sender immediately by reply email and then delete it from your system. Any disclosure, forwarding or copying of this email or its attachments is expressly prohibited. ************************************************************@~|!+
From: ROUSSEL Yohann <yohann.roussel@criltelecom.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 10:52:44 +0200 Send reply to: java@u-strasbg.fr Bon en theorie ton histoire de creer la Frame cote client puis d'envoyer ca vers un client devrait marcher mais j'ai quand meme quelques doutes quant aux listener et autre. pour ce qui est de la deserialisation cote client de classes que tu as developpees cherche un tutorial RMI et regarde la notion de codebase, ca te permet de definir une URL a laquelle le client peut aller chercher les classe qui lui manque (c'est juste un parametre a positionner au lancement du client). Sinon ici nous utilisons aussi le protocole JNLP (Java Web Start precedement cite est une implem du protocole) et je pense que ca conviendrait tout a fait a ton besoin (ce que tu veux faire y ressemble quand meme beaucoup) http://pharos.inria.fr/Java/query.jsp?kind=fulltext&mode=all&text=JNLP > -----Message d'origine----- > De : Erik Mazoyer [mailto:erik.mazoyer@hyperoffice.fr] > Envoyé : mardi 22 mai 2001 10:10 > À : java@u-strasbg.fr > Objet : RE: RMI et interface > > > Bonjour Guillaume > > > Le principal problème des écrans HTML est leur pauvreté au niveau > interface > > graphique et possibilités d'impression. > > Si l'on veut faire des applications vraiment ergonomiques avec des > > possibilités graphiques, il va falloir jouer avec le HTML dynamique > (bonjour > > la compatibilité des browsers), rajouter des applets...etc. > > Je partage tout à fait ton avis. > Je me "bat" souvent avec mes clients et mes graphistes pour > créer des sites > le plus possible compatible HTML 3. > Et de n'inclure Javascript, HTML dynamique, applets, etc, que > dans les cas > vraiment importants. > Et le coût de la page monte vite en flèche (test sous > Mac/PC/unix x IE3, IE4 > IE5, N3, N4, N6 = 18 plateformes). > Et pour l'instant on ne prend pas en compte Opera :-) > > > La mode actuelle veut que les applications Web passent > forcément par du > > HTML. On a donc banni les client/serveur d'antan qui > présentaient pourtant > > des clients évolués au niveau GUI pour des raisons de déploiement. > > Il reviennent :-) > Corba, RMI,... sont directement issus de ces "client/serveur d'antan". > On a juste pris un chemin un peu long :-) > > > Donc si ton problème est de déploiement d'applications > Java, je suis sûr > > qu'Olivier D. va te trouver une URL d'enfer sur Pharos pour > t'aider dans > tes > > recherches! ;-)). En plus passer du Swing dans RMI, heu... > > En fait, c'est juste le compiler que je désire faire passer. > Le serveur construisant l'interface (avec le moteur > d'interrogation) pour le > client. > En gros : > Le client : "Cher serveur, que dois je afficher à > l'utilisateur pour lui > donner accès à xxxx" > Le serveur : "Mon cher client utilisez la classe MaFrame pour > l'interface. > Vous la trouverez ici" > Le client : "Merci" > > > je pense que tu risques de rencontrer des problèmes! > > C'est ce que je cherche à évaluer. Quelqu'un a t'il déjà tenté cette > expérience ? Je vais faire une maquette simple pour tester. Je vous > ferais part des résultats. > > > Voila c'était mes 2 euros cents sur le sujet... > > Merci > > Cordialement, > > -------------------------------------------------------------------- > Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 > Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél > erik.mazoyer@hyperoffice.fr > > -----Message d'origine----- > De: Guillaume Helle [mailto:ghelle@capgemini.fr] > Date: mardi 22 mai 2001 10:40 > À: java@u-strasbg.fr > Objet: Re: RMI et interface > > > Bonjour, > > je me permet de m'immiscer dans la conversation pour faire > part de ma longue > expérience sur les applications Web...;-) > > D'abord je n'aime pas le terme "client léger" lorsque l'on parle d'un > browser...surtout IE. Il n'y a qu'à voir les ressources qu'il utilise > pour se rendre compte qu'il n'est pas plus léger qu'une JVM. > > Le principal problème des écrans HTML est leur pauvreté au > niveau interface > graphique et possibilités d'impression. > Si l'on veut faire des applications vraiment ergonomiques avec des > possibilités graphiques, il va falloir jouer avec le HTML > dynamique (bonjour > la compatibilité des browsers), rajouter des applets...etc. > De plus les impressions ne sortent souvent pas le même > résultat en fonction > du browser et tout ce qui passe à droite de l'écran, pourtant > accessible via > l'ascenseur, est tronqué. On est donc souvent obligé > d'utiliser des outils > de Report pour générer du PDF imprimable ou de se torturer > pour dessiner les > écrans HTML (Ex.: pas de tables avec un nombre de colonnes > dynamiques). > > La mode actuelle veut que les applications Web passent > forcément par du > HTML. On a donc banni les client/serveur d'antan qui > présentaient pourtant > des clients évolués au niveau GUI pour des raisons de déploiement. > Il faut bien se rendre compte que tout cela à changé. > Maintenant on peut > très bien déployer des applications Java via le Web et les > mettre à jour de > façon automatique et transparente pour l'utilisateur. Webstart de SUN > (gratos) en est un des exemples. On peut donc avoir des clients dignes > de ce nom avec une véritable interface graphique ergonomique qui ne pose > pas de problème de déploiement. > > Côté impression je reconnais qu'imprimer en Java demande > encore bien des > efforts au niveau développement et que l'on préfère passer > encore par des > reports (ne serait-ce que pour garder des traces des écrans > et des états). > Par contre on trouve ce genre d'outils en Java (Elixir, > Cocoon,...) ce qui > permet de garder une certaine homogénéité dans la solution > (100% Java). > > Donc si ton problème est de déploiement d'applications Java, > je suis sûr > qu'Olivier D. va te trouver une URL d'enfer sur Pharos pour > t'aider dans tes > recherches! ;-)). En plus passer du Swing dans RMI, heu... je > pense que tu > risques de rencontrer des problèmes! > > Si tu as choisis Swing comme interface graphique, cela me > semble correct et > côté performances, hormis le lancement de la JVM qui est > toujours long, avec > les PC actuels (même vieux de qqs années) cela ne pose pas de > problèmes. > > En conclusion le choix HTML/Java se pose en fonction des > besoins d'interface > de l'application mais on peut facilement proposer l'un ou l'autre. Le > problème vient souvent de l'utilisateur qui veut une application Web > dans son navigateur préféré... C'est lui qu'il faut convaincre (et > souvent aussi les responsables informatique) et ce n'est pas toujours > évident. > > Voila c'était mes 2 euros cents sur le sujet... > > Amicalement, > > Guillaume Helle > CAP GEMINI ERNST & YOUNG > Division SUD-OUEST > 05.61.31.54.19 > ghelle@capgemini.fr > > >
From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 11:05:46 +0200 Send reply to: java@u-strasbg.fr > Les protocoles d'objets distribués, comme CORBA et RMI, permettent de > voir des objets distants de manière > transparente. Par conséquent, tu vas créer sur ton serveur une classe Frame qui sera activée par tes clients, > pas vrai ? Dans ce cas-là, ce qui se passe dans cette classe, même si ça implique un traffic réseau énorme, ne > regarde pas le client, tu as donc toute liberté pour inclure toutes les classes que tu veux. Est-ce que je me > trompe ? D'après ce que j'ai compris (je n'en suis qu'à l'étude :-), RMI repose sur la serialisation. Hors la serialisation, j'emploie ça depuis longtemps et elle implique que le programme qui desérialise connaisse la classe. En fait on ne sérialise pas une classe, on sérialise l'instance d'une classe. Le classe doit être connue. Mon problème est que le client ne connait pas la classe. Il faut donc lui donner la possibilité de la charger. Ma question devient : Est-ce que RMI me donne cette posibilité, ou dois-je definir un ClassLoader ? -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr -----Message d'origine----- De: Nicolas Delsaux [mailto:nicolas.delsaux@free.fr] Date: mardi 22 mai 2001 10:42 À: java@u-strasbg.fr Objet: RE: RMI et interface En réponse à Erik Mazoyer <erik.mazoyer@hyperoffice.fr>: Salut, je vais juste répondre à une partie de ta question, celle concernant le ClassLoader. > 3) Faut-il implémenter un classloader pour aller chercher les classes > dérivant de SWING sur le serveur ? Peut-être que oui, effectivement, vu que tu souhaites aller chercher des classes ailleurs que dans ton espace local... > > 4) Est-ce compliquer d'écrire un classloader qui aille lire les classes > disponible sur le serveur depuis le client (avec les problème de > recouvrement possible des classes déclarées simultanément sur le serveur > et > le client (toutes les classes natives du JRE à priori)) ? Non. Non ce n'est pas compliqué, et non il n'y a pas de risque d'erreur de recouvrement. Depuis Java 2, la méthode préconisée pour surcharger le ClassLoader consiste justement à modifier le lieu, et éventuellement l'ordre, de recherche des classes chargées, grâce à la méthode findClass. En conséquence, tu as seulement à surcharger cette méthode pouyr que les classes soient recherchées dans un espace de référence si elles correspondent à une certaine convention de nommage (par exemple org.mesclasses.amoi). Tes histoires de recouvrement ne risquent donc pas d'arriver, sauf pour ta classe d'uinterface, pour laquelle j'ai justement une question. Les protocoles d'objets distribués, comme CORBA et RMI, permettent de voir des objets distants de manière transparente. Par conséquent, tu vas créer sur ton serveur une classe Frame qui sera activée par tes clients, pas vrai ? Dans ce cas-là, ce qui se passe dans cette classe, même si ça implique un traffic réseau énorme, ne regarde pas le client, tu as donc toute liberté pour inclure toutes les classes que tu veux. Est-ce que je me trompe ? > > -------------------------------------------------------------------- > Erik Mazoyer, Chef de projet > HyperOffice > 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex > Tél. 01 41 96 96 76 > Fax 01 41 96 96 77 > Mél erik.mazoyer@hyperoffice.fr Nicolas Delsaux PS : concernant les ClassLoaders, tu peux regarder sur la pseudo-archive, ou sur le java-channel, ou sur le site d'Olivier Dedieu, qui fournit il me semble un assez bon exemple de ClassLaoder à CLASSPATH extensible.
From: Thierry Janaudy <tjanaudy@voxgeneration.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 10:11:37 +0100 Send reply to: java@u-strasbg.fr =>Erik Mazoyer, Chef de projet =>Mon problème est que le client ne connait pas la classe. Il =>faut donc lui =>donner la possibilité de la charger. =>Ma question devient : =>Est-ce que RMI me donne cette posibilité, ou dois-je definir =>un ClassLoader =>? Oui aux deux. Tu peux avoir une approche stubless (JDK 1.3), le lien ci-dessous est de Rickard Oberg (le petit genie qui a developpe jBoss www.jboss.org) http://archives.java.sun.com/cgi-bin/wa?A2=ind0009&L=rmi-users&P=R3631&D=1&H=0&O=D&T=1 JDK1.2: http://archives.java.sun.com/cgi-bin/wa?A2=ind0009&L=rmi-users&P=R10447&D=1&H=0&O=D&T=1 -- Thierry ************************************************************@~|!+ This email and any attachments are confidential and are intended for the addressee(s) only. If you are not the intended recipient, please notify the sender immediately by reply email and then delete it from your system. Any disclosure, forwarding or copying of this email or its attachments is expressly prohibited. ************************************************************@~|!+ From: Erik Mazoyer <erik.mazoyer@hyperoffice.fr> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 11:53:29 +0200 Send reply to: java@u-strasbg.fr Merci pour toute vos réponses =>Est-ce que RMI me donne cette posibilité, ou dois-je definir =>un ClassLoader > Oui aux deux. Tu peux avoir une approche stubless (JDK 1.3), > le lien ci-dessous est de Rickard Oberg (le petit genie qui > a developpe jBoss www.jboss.org) Je suis entrain de lire son livre sur RMI. Passionnant :-) > Sachant que j'attends la reponse concernant Swing :-),... L'application est distribuée simultanément sous forme de cédérom et sous forme de client/serveur. L'interface doit être identique dans les deux cas. Certaines fonctionnalités, telles que la gestion de sélection (sans enchainer trop d'écrans), l'édition de texte enrichit, ne sont pas simple en HTML. > Java Web Start: Tres utile pour un client lourd comme le tien, gere les > versions, et parfaitement viable dans un Intranet. > http://java.sun.com/products/javawebstart/index.html >...nous utilisons aussi le protocole JNLP (Java Web Start precedement > cite est une implem du protocole) et je pense que ca conviendrait tout a > fait a ton besoin (ce que tu veux faire y ressemble quand meme beaucoup) > http://pharos.inria.fr/Java/query.jsp?kind=fulltext&mode=all&text=JNLP Merci, en effet cela ressemble comme deux goutes d'eau à mon problème de mise à jour de client. Je vais creusé par la :-) I'll be back :-) Cordialement, -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél erik.mazoyer@hyperoffice.fr
From: "Cedric Beust" <cedric@beust.com> To: "Guillaume Helle" <ghelle@capgemini.fr>, <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 07:15:41 -0700 Send reply to: java@u-strasbg.fr > From: Guillaume Helle [mailto:ghelle@capgemini.fr] > Si tu as choisis Swing comme interface graphique, cela me semble > correct et côté performances Ca devient raisonnble mais les applications Swing ne s'integrent toujours pas bien avec le systeme hote. Par exemple, sous Windows, impossible d'utiliser la roulette, la taskbar, les file dialogs avances (utilisant la completion automatique), etc... Ce qui fait que Swing est et restera probablement toujours une toolkit marginale qui ne peut pas rivaliser en terme de fonctionnalites et d'apparence professionnelle avec des applis natives ou DHTML. -- Cedric
Send reply to: "Chris Ravenscroft" <Chris.Ravenscroft@alcatel.com> From: "Chris Ravenscroft" <Chris.Ravenscroft@ind.alcatel.com> To: <java@u-strasbg.fr> Subject: Re: RMI et interface Date sent: Tue, 22 May 2001 10:26:14 -0700 Concernant la roulette, il y a une API dans le Jdk1.3, bon il faut l'utiliser explicitement, et aussi la promesse du support dans le 1.4. Est-ce que Swing en soi ne serait pas compatible avec cette API ? -C ................................................................... -Chris Ravenscroft Principal Software Engineer, Alcatel NMS - Calabasas / (818) 878-5094 ----- Original Message ----- From: "Cedric Beust" <cedric@beust.com> To: "Guillaume Helle" <ghelle@capgemini.fr>; <java@u-strasbg.fr> Sent: Tuesday, May 22, 2001 7:15 AM Subject: RE: RMI et interface > From: Guillaume Helle [mailto:ghelle@capgemini.fr] > Si tu as choisis Swing comme interface graphique, cela me semble > correct et côté performances Ca devient raisonnble mais les applications Swing ne s'integrent toujours pas bien avec le systeme hote. Par exemple, sous Windows, impossible d'utiliser la roulette, la taskbar, les file dialogs avances (utilisant la completion automatique), etc... Ce qui fait que Swing est et restera probablement toujours une toolkit marginale qui ne peut pas rivaliser en terme de fonctionnalites et d'apparence professionnelle avec des applis natives ou DHTML. -- Cedric
From: "Cedric Beust" <cedric@beust.com> To: "Chris Ravenscroft" <Chris.Ravenscroft@alcatel.com>, <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Tue, 22 May 2001 10:30:30 -0700 Send reply to: java@u-strasbg.fr > From: Chris Ravenscroft [mailto:Chris.Ravenscroft@ind.alcatel.com] > Concernant la roulette, il y a une API dans le Jdk1.3, bon il faut > l'utiliser explicitement, et aussi la promesse du support dans le 1.4. > Est-ce que Swing en soi ne serait pas compatible avec cette API ? Ce genre de support ne peut etre fourni que via des bibliotheques natives. Et ca va a l'encontre de la philosophie (stupide) de Sun a ce sujet. -- Cedric
From: Thierry Janaudy <tjanaudy@voxgeneration.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Wed, 23 May 2001 09:46:06 +0100 Send reply to: java@u-strasbg.fr =>Ce genre de support ne peut etre fourni que via des =>bibliotheques natives. =>Et ca va a l'encontre de la philosophie (stupide) de Sun a ce sujet. => =>-- =>Cedric Entierement d'accord. Pour la petit histoire jEdit possede un plug-in "MouseWheel", je l'utilise tous les jours et je trouve cela genial: http://plugins.jedit.org/plugins/WheelMouse -- Thierry ************************************************************@~|!+ This email and any attachments are confidential and are intended for the addressee(s) only. If you are not the intended recipient, please notify the sender immediately by reply email and then delete it from your system. Any disclosure, forwarding or copying of this email or its attachments is expressly prohibited. ************************************************************@~|!+
Send reply to: "Guillaume Helle" <ghelle@capgemini.fr> From: "Guillaume Helle" <ghelle@capgemini.fr> To: <java@u-strasbg.fr> Subject: Re: RMI et interface Date sent: Wed, 23 May 2001 11:17:29 +0100 Organization: Cap Gemini > =>Ce genre de support ne peut etre fourni que via des > =>bibliotheques natives. > =>Et ca va a l'encontre de la philosophie (stupide) de Sun a ce sujet. > => =>-- =>Cedric D'accord pour la sourie mais pas pour les bibliotheques natives. Lorsque l'on regarde JAI ou JMF, on a bien des libs natives dépendantes de la plateforme cibles qui sont livrées par SUN... Ce n'est pas dans le SDK/JDK mais cela fait quand même partie des APIs SUN qui sont de plus en plus utilisées... Amicalement, Guillaume Helle CAP GEMINI ERNST & YOUNG Division SUD-OUEST 05.61.31.54.19 ghelle@capgemini.fr
From: "Cedric Beust" <cedric@beust.com> To: "Guillaume Helle" <ghelle@capgemini.fr>, <java@u-strasbg.fr> Subject: RE: RMI et interface Date sent: Wed, 23 May 2001 07:56:31 -0700 Send reply to: java@u-strasbg.fr > From: Guillaume Helle [mailto:ghelle@capgemini.fr] > D'accord pour la sourie mais pas pour les bibliotheques natives. Lorsque > l'on regarde JAI ou JMF, on a bien des libs natives dépendantes de la > plateforme cibles qui sont livrées par SUN... Oui. En fait, meme AWT a un support natif, ce n'est pas de ca que je parlais. La "philosophie stupide" est celle consistant a adopter un ensemble de fonctionnalites correspondant au plus grand denominateur commun entre les plateformes. Il devrait y avoir des exceptions ponctuelles permettant aux toolkits d'utiliser toutes les fonctionnalites auxquelles les utilisateurs sont habitues sur une plateforme donnee (wheelmouse, iconification, drag and drop etendu, completion de noms de fichiers dans les boites de dialogue, etc...). Bien sur, ca devrait s'appliquer egalement aux plateformes non-Windows. -- Cedric
