Je pense que Corba est vraiment un super truc, mais qu'il est completement inadapte a la problematique des composants graphiques.
La force de Corba, c'est:
- composant independant de la plate-forme
- composant independant du langage
- distribution des composants sur plusieurs machines
Ces avantages ont evidemment un cout:
- toutes les communications entre composant se font par un IDL et via le reseau. Declarer les interfaces est assez lourd
- parce que les composants sont reclames a un serveur, ca prend pas mal de temps d'activer un composant
- l'ensemble du framework est relativement lourd a apprendre, a installer et a gerer
- la consommation memoire du tout n'est pas forcement negligeable. Le marshalling et la communication reseau introduisent des delais
- le debug de tout ca est une horreur. Quand le serveur tombe, il te reste plein de processus en background a tuer.
Apres une reflexion de fond, il apparait que les besoins en terme de communication pour un bureau comme KDE sont:
- pouvoir notifier toutes les applications d'un evenment facilement (ejection du lecteur CD, nouveau mail, application lancee, ...)
- d'etablir des canaux de communication entre applications pour echanger des informations relativement simples (ouvre moi cette page web, affiche moi le lien bidule dans la barre d'etat, ...)
- faire des requetes sur les applications : donne moi la liste de tous les composants editeur de texte, dis moi si kmail est deja lance, ...
Tout ca devant s'executer relativement rapidement puisqu'il y a une interaction avec l'utilisateur.
Cote composant graphique, les besoins sont:
- etre capable d'associer un role a un composant et de faire des recherches par role
- charger le composant tres rapidement de facon a ce que l'utilisateur ne voit pas qu'il y a une distinction entre l'application (konqueror) et le composant (khtml).
- avoir une structure globale tres legere pour que ca se charge vite
- le tout doit etre facile a apprendre de facon a ce que les developpeurs qui travaillent sur leur temps libre puisse facilement ecrire des composants.
En regardant ces listes, on voit que les points forts de Corba ne font par partie des besoins, alors que certaines de ses caracteristiques vont poser des problemes. Typiquement, sur un bureau, toutes les applications du bureau sont lancees par le meme utilisateur, sur le meme ordinateur. L'idee d'avoir un konqueror ou le composant khtml serait en train de s'executer sur un autre ordinateur parait un peu incongru. Le besoin de travailler sur plusieurs ordinateurs en meme temps est deja rempli par X ou par vnc.
Donc je ne crache pas sur Corba en general, mais sur cette application de Corba en particulier. Les technos developpes par KDE lorsqu'ils se sont rendu compte de la problematique que je viens d'exposer (c'est pas moi qui l'ai invente, je l'ai lue) repondent parfaitement aux besoins enonces avec rien de trop:
- DCOP est leger et permet de faire tout ce qui est dit
- kpart est leger, ca se charge tres vite puisque c'est une bibliotheque partagee
- pour ce qui est de la communication entre le composant et son applciation, on utilise un simple appel de fonction C++ puisque le composant est charge directement dans l'espace d'adressage de l'application
- pas de marshlling
- hyper simple a utiliser, pas d'IDL, pas de doc speciale a lire, tout marche avec du C++ normal: l'appli doit heriter de kparthost et le composant de kpart.
Et pour les "oui mais si jamais je veux quand meme avoir un composant independant de l'appli qui l'embarque", c'est encore possible. Gtk et Qt implementent tous les deux un mecanisme qui permet d'incruster n'importe quelle fenetre X dans une autre fenetre (XEmbed). C'est ce qu'on utilise pour kvim. Avec ca, on peut lancer un programme quelconque sur une machine distante via le serveur X et l'utiliser comme composant.
[^] # Re: XAML et l'avenir de GNOME
Posté par Philippe F (site web personnel) . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 3.
La force de Corba, c'est:
- composant independant de la plate-forme
- composant independant du langage
- distribution des composants sur plusieurs machines
Ces avantages ont evidemment un cout:
- toutes les communications entre composant se font par un IDL et via le reseau. Declarer les interfaces est assez lourd
- parce que les composants sont reclames a un serveur, ca prend pas mal de temps d'activer un composant
- l'ensemble du framework est relativement lourd a apprendre, a installer et a gerer
- la consommation memoire du tout n'est pas forcement negligeable. Le marshalling et la communication reseau introduisent des delais
- le debug de tout ca est une horreur. Quand le serveur tombe, il te reste plein de processus en background a tuer.
Apres une reflexion de fond, il apparait que les besoins en terme de communication pour un bureau comme KDE sont:
- pouvoir notifier toutes les applications d'un evenment facilement (ejection du lecteur CD, nouveau mail, application lancee, ...)
- d'etablir des canaux de communication entre applications pour echanger des informations relativement simples (ouvre moi cette page web, affiche moi le lien bidule dans la barre d'etat, ...)
- faire des requetes sur les applications : donne moi la liste de tous les composants editeur de texte, dis moi si kmail est deja lance, ...
Tout ca devant s'executer relativement rapidement puisqu'il y a une interaction avec l'utilisateur.
Cote composant graphique, les besoins sont:
- etre capable d'associer un role a un composant et de faire des recherches par role
- charger le composant tres rapidement de facon a ce que l'utilisateur ne voit pas qu'il y a une distinction entre l'application (konqueror) et le composant (khtml).
- avoir une structure globale tres legere pour que ca se charge vite
- le tout doit etre facile a apprendre de facon a ce que les developpeurs qui travaillent sur leur temps libre puisse facilement ecrire des composants.
En regardant ces listes, on voit que les points forts de Corba ne font par partie des besoins, alors que certaines de ses caracteristiques vont poser des problemes. Typiquement, sur un bureau, toutes les applications du bureau sont lancees par le meme utilisateur, sur le meme ordinateur. L'idee d'avoir un konqueror ou le composant khtml serait en train de s'executer sur un autre ordinateur parait un peu incongru. Le besoin de travailler sur plusieurs ordinateurs en meme temps est deja rempli par X ou par vnc.
Donc je ne crache pas sur Corba en general, mais sur cette application de Corba en particulier. Les technos developpes par KDE lorsqu'ils se sont rendu compte de la problematique que je viens d'exposer (c'est pas moi qui l'ai invente, je l'ai lue) repondent parfaitement aux besoins enonces avec rien de trop:
- DCOP est leger et permet de faire tout ce qui est dit
- kpart est leger, ca se charge tres vite puisque c'est une bibliotheque partagee
- pour ce qui est de la communication entre le composant et son applciation, on utilise un simple appel de fonction C++ puisque le composant est charge directement dans l'espace d'adressage de l'application
- pas de marshlling
- hyper simple a utiliser, pas d'IDL, pas de doc speciale a lire, tout marche avec du C++ normal: l'appli doit heriter de kparthost et le composant de kpart.
Et pour les "oui mais si jamais je veux quand meme avoir un composant independant de l'appli qui l'embarque", c'est encore possible. Gtk et Qt implementent tous les deux un mecanisme qui permet d'incruster n'importe quelle fenetre X dans une autre fenetre (XEmbed). C'est ce qu'on utilise pour kvim. Avec ca, on peut lancer un programme quelconque sur une machine distante via le serveur X et l'utiliser comme composant.