> Il suffit de spécifier le protocole de communication.
C'est bien la le probleme. Il faut specifier le protocole de communication, et comme toutes les applis sont developpees de facon completement independantes, aucune n'a un protocole de communication commun. Pour celles qui en ont un.
Sous KDE, je sais que si j'utilise DCOP, je pourrais deja communiquer avec toutes les applis KDE. Je n'ai pas besoin de toutes les patcher une par une avec mon protocole de communication que j'ai perdu du temps a developper, je peux reutiliser de l'existant (applis + protocole) et ca me permettra de me concentrer sur mon appli a moi. C'est hyper important.
La difference entre un composant et une bibliotheque, c'est que le composant est bien plus integre dans ton appli. La ou une bibliotheque ne fait que fournir des points d'entrees, le composant va fournir des mecanismes d'integration standard que tu n'aura pas a gerer. Pour illustrer, les composants KDE sont bases sur des bibliotheques partagees (donc il y a bien un rapport). Quand tu demandes le composant, KDE va prendre en charge lui-meme:
- la localisation du composant dans ton systeme
- l'utilisation du composant le plus approprie selon tes besoins preferences (il peut y en avoir plusieurs qui sont concurrents - gecko vs kthml, kvim vs kwrite)
- le chargement dynamique de ce composant (evidemment, tu peux mettre tout en statique mais c'est plus lourd)
- l'integration des menus du composants dans le menu de ton appli
- l'integration des racourcis clavier
- la gestion de la configuration
- la gestion de l'affichage.
> Alors avoir des composants style browser html dans ton appli, à part bouffer des ressources
Ca a l'air de te surprendre, mais parfois tu as besoin de composants, et pas pour le plaisir de bouffer des resources. Par exemple, toujours sous KDE, si tu tapes info:// ou man://, tu peux acceder a une page man ou info. Ils auraient pu redevelopper tout l'affichage de ces pages mais ils ont prefere convertir rapidement les pages man/info en html avec des outils existants et utiliser le composant html.
Autre exemple, tu as un client mail, un client news, un environnement de dev, un editeur de page web. Tous ont besoin de developper un editeur de texte. Il est beaucoup plus efficace de developper un ou deux composants "editeur de texte" qui pourront etre utilises par toutes les applis, et ameliores par plusieurs personnes en meme temps, plutot que chacun developpe son editeur de texte. Passons du temps la ou c'est util, pas la ou des tas de gens ont deja passe du temps.
[^] # Re: Reaction mitigee
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 10.
C'est bien la le probleme. Il faut specifier le protocole de communication, et comme toutes les applis sont developpees de facon completement independantes, aucune n'a un protocole de communication commun. Pour celles qui en ont un.
Sous KDE, je sais que si j'utilise DCOP, je pourrais deja communiquer avec toutes les applis KDE. Je n'ai pas besoin de toutes les patcher une par une avec mon protocole de communication que j'ai perdu du temps a developper, je peux reutiliser de l'existant (applis + protocole) et ca me permettra de me concentrer sur mon appli a moi. C'est hyper important.
La difference entre un composant et une bibliotheque, c'est que le composant est bien plus integre dans ton appli. La ou une bibliotheque ne fait que fournir des points d'entrees, le composant va fournir des mecanismes d'integration standard que tu n'aura pas a gerer. Pour illustrer, les composants KDE sont bases sur des bibliotheques partagees (donc il y a bien un rapport). Quand tu demandes le composant, KDE va prendre en charge lui-meme:
- la localisation du composant dans ton systeme
- l'utilisation du composant le plus approprie selon tes besoins preferences (il peut y en avoir plusieurs qui sont concurrents - gecko vs kthml, kvim vs kwrite)
- le chargement dynamique de ce composant (evidemment, tu peux mettre tout en statique mais c'est plus lourd)
- l'integration des menus du composants dans le menu de ton appli
- l'integration des racourcis clavier
- la gestion de la configuration
- la gestion de l'affichage.
> Alors avoir des composants style browser html dans ton appli, à part bouffer des ressources
Ca a l'air de te surprendre, mais parfois tu as besoin de composants, et pas pour le plaisir de bouffer des resources. Par exemple, toujours sous KDE, si tu tapes info:// ou man://, tu peux acceder a une page man ou info. Ils auraient pu redevelopper tout l'affichage de ces pages mais ils ont prefere convertir rapidement les pages man/info en html avec des outils existants et utiliser le composant html.
Autre exemple, tu as un client mail, un client news, un environnement de dev, un editeur de page web. Tous ont besoin de developper un editeur de texte. Il est beaucoup plus efficace de developper un ou deux composants "editeur de texte" qui pourront etre utilises par toutes les applis, et ameliores par plusieurs personnes en meme temps, plutot que chacun developpe son editeur de texte. Passons du temps la ou c'est util, pas la ou des tas de gens ont deja passe du temps.