|
nous nous intéressons à Windows 32 bits, et cela en adéquation avec la demande du marché.
A l'origine O2 a été porté sur les environnements Unix. Mais devant l'évolution du marché, nous devons répondre à la demande sur les plates-formes Intel. Or il était impossible de faire fonctionner O2 sous DOS ou sous Windows. En revanche avec Windows 95 et plus particulièrement Windows NT, les dernières contraintes on été levées. De plus le développement Web est très agréable en environnement objet, notamment avec O2 qui permet de donner des vues Web aux objets et générer des pages HTML automatiquement.
Et DELPHI ?
DELPHI est un marché en pleine croissance. Nous avons déjà répondu à la demande des développeurs en offrant une solution pour Visual C++, notamment pour les stations de travail puissantes, mais aussi sous ODBC et la norme CORBA. En effet, bien qu'O2 soit objet, il est possible d'offrir une vue relationnelle pour que des outils puissent travailler avec du SQL standard sur O2. Cela représente une réelle ouverture au marché de la micro-informatique. La technique est la suivante : on reçoit du SQL qui est traduit en OQL (standard d'interrogation ODMG) qui s'exécute sur les objets stockés. C'est ce qu'on appelle des vues virtuelles.
Cependant CORBA répond plus à notre attente car il est possible d'obtenir des vues d'objets O2 sous forme IDL. C'est plus agréable, il y a moins de contraintes et c'est plus performant. Or ORBIX, l'un des produits phare du monde CORBA, a une interface DELPHI, et les fournisseurs de CORBA commencent à s'ouvrir au monde COM/DCOM (norme objet du monde Windows 32 bits de Microsoft) à cause du marché potentiel.
C'est ainsi qu'à travers ORBIX il est possible de générer une interface DELPHI et les objets O2 sont vus comme des objets DELPHI.
Et vous voudriez développer votre propre solution DELPHI ?
C'est une possibilité, à moins que nous n'attendions l'arrivée du C++ builder de Borland. De toute manière la solution ORBIX fonctionne. On s'attend à de bonnes performances si le cache d'objet O2 et DELPHI se trouvent tous les deux du côté client du système.
Nous avons déjà trouvé des acteurs dans différents secteurs d'activité ayant une volonté de mettre en oeuvre cette première approche.
La seconde approche consisterait à utiliser une API pour accéder aux objets O2 dans un programme DELPHI, car nous savons que DELPHI est capable d'interroger dynamiquement ses objets pour en connaître la forme et l'actuelle API d'O2 permet aussi cela. Enfin il n'est pas impossible d'envisager de fournir des objets d'interface entre O2 et DELPHI.
Quel est votre point de vue sur DELPHI ?
J'en pense ce qu'en pensent mes client qui en sont fan...
En fait c'est un bon système, simple, convivial, performant et ... objet.
|
|
