Esoteric Component Object Model (ECOM) Whitepaper
Abstract:
La technologie ECOM a pour but de faciliter et promouvoir l'utilisation des modèles à composants
dans la programmation notemment pour le developpement de jeux.
Description de certaines technologies de composants existantes:
MSCOM:
La technologie composants de Microsoft est fortement présent dans Windows depuis 1995.
MSCOM est 'cross-language' rendu possible grâce à une IDL (Interface Definition Language) propre,
on peut l'utiliser à partir du C, C++, Visual Basic, Delphi, JScript, ... .
MSCOM est une réalité 'cross-plateform' dans le monde Windows (Win9x, WinNT, WinCE), mais étant une
technologie très propriétaire l'implémentation sur des plateformes Unix ne semble pas répandue.
Les composants sont très complexe à programmer en C++, l'utilisation des ATL (Active Template Library)
rend le code dépendant du compilateur Microsoft Visual C++ (aucun port des ATL connus à ce jour).
Permet des appel in-process, out-process et en remote (machine disante).
XPCOM (3):
Créé par le groupe Mozilla, les bases sont les même que MSCOM, tout en restant totalement incompatible,
sans doute pour éviter toute limitation future que ça aurait demandé. Pour l'instant ne marche qu'avec
du C++ ou du JScript, permet des appel in-process, out-process et en remote (machine disante) utilise une
IDL propriétaire.
UNO (4) (Universal Network Objects):
La technologie de OpenOffice relativement semblabe à XPCOM, peut s'utiliser avec Java, C, C++. Utilise une
IDL propre. Un grand avantage c'est qu'il semble que les execptions soient gérées (à étudier).
CORBA:
Je n'ai pas trop fait de recherches dessus, c'est surtout (uniquement?) pour des architectures distribuées
donc très peu pour les jeux.
XPLC (5):
XPLC ("Cross-Platform Lightweight Components") is a component system that will provide extensibility
and reusability both inside and between applications, while being portable across platforms (and languages)
and having the lowest possible overhead (both in machine resources and programming effort).
N'est pas compatible avec MSCOM, mais contient pas mal de points interressants.
Java RMI:
Etant donné que Java utilise CORBA depuis peu, je pense que ca devait pas être interressant
Présentation de ECOM:
Alors on peut se demander pourquoi avec déjà au moins 4 produit de composant, faut-il en créer un autre.
En fait, le problème est que ces technologies permettent de faire des choses très compliquées (une
application qui as des bouts qui tournent sur plusieurs machines en mêmes temps), mais dans le même
temps elles demandent des choses assez lourdes; tel l'enregistrement des composants, si c'est logique
dans un environnement complexe (le composant est sur une autre station), ce n'est pas vraiment adapter
aux domaines des jeux vidéos, ou en général tout se trouve dans le même répertoire.
La technologie ECOM a pour but de résoudre ce problème, en proposant une technologie simple à implémenter
et a utiliser.
Objectif:
Instanciation et utilisation d'une interface d'un composant qui puisse servir de mouteur 2D:
EComPtr<IDisplay2D> moteur2D;
moteur2D.InstanciateByID( CATID_Display2D );
moteur2D->DrawAStupidThing( ... );
moteur2D.InstanciateByID( CLSID_DirectGraphics8 );
ECOMPTR(IDisplay3D) moteur3D = moteur2D;
moteur3D->DrawAStupid3DThing( ... );
...
}
Pour l'ecriture d'un composant:
TODO
Comme on peut le voire, l'implémentation d'un composant demmande un peu plus de code et se base sur
une certaine convention de nomage (e.g. l'implémenteur de IXxx se nomme ImplIXxx) afin de réduire
le travail du developpeur.
L'utilisation des GUID (les chiffres qui identifient les interface, classes et catégories) n'est pas
nécessaire mais leurs déclarations (qui semble inimportante vu qu'ils ne semblent pas servir) reste
obligatoire (si qq1 a une idée advisory_at_free.fr ) p'tre en générant un guid à partir du nom d'interface
mais ca me semble impossible.
Méthodes d'instanciations et recherches des composants:
Pour éviter d'avoir besoin d'enregistrer ses composants, ECOM peut utiliser different moyen pour trouver
les composant à instancier:
+ Recherche à partir d'un base de donnée locale (un fichier dans le repertoire courant) qui listes les
composants instanciables.
+ Recherche dans des répertoires (dont le repertoire courant) en questionnant toutes les bibliothèques. (FAIT)
+ Utilisation du registre global
+ Chargement d'un fichier spécifié (e.g. Gfx::Display pour .\Gfx\Display.dll sous Win) dans ce cas il n'est
pas necessaire de spécifier le composant à instancier; dans quel cas le composant par défaut de la
bibliothèque sera pris (Identifiant spécial).
+ Généraliser le système de chargement par des plugins?
Problèmes insolubles qui ne trouverons sans doutes pas de réponses:
+ Passage des execption du composant au client: les implémentation sont spécifiques aux compilateurs (comment
fait UNO?).
+ Templates: je pense pas qu'on pourra les utiliser dans les interfaces, vu que les template sont résolues
durant la compilation et que le composant n'est pas compiler avec le client.
Ressources:
(1) http://casteyde.christian.free.fr/objet/
(3) http://www.mozilla.org/projects/xpcom/
(4) http://udk.openoffice.org/
(5) http://xplc.sourceforge.net/
Sébastien 'Jester' Derivaux
esotech_at_free.fr