Discussion :

[randriano]

Salut tout le monde !

Vraiment novice en programmation sous LINUX alors que la programmation sous Linux s'avère l'avenir de l'informatique d'entreprise, je sens que je suis allé trop loin en technologie Microsoft, maintenant, j'aimerais faire la même chose sous Linux; comment créer un serveur OLE ou un contrôle ActiveX sous ce système d'exploitation.
Ou existe-t-il une technologie pareille dans le monde linuxien, quoi donc ?

[gangsoleil]

Bonjour,

Ce dont tu parles est spécifique au monde Windows. Il existe surement des solutions permettant d'obtenir le même résultat sous LInux, mais encore faut-il que l'on sache de quoi tu parles, ou plus exactement ce que tu souhiates faire (dans la mesure où ce que tu cherches n'existe pas, il faut se concentrer sur certaines fonctionalités spécifiques pour pouvoir trouver un équivalent).

[randriano]

En effet c'est ça, je cherche des solutions permettant d'obtenir le même résultat sous Linux.

[Hibou57]

Je me posais la question justement aussi ces derniers temps : ce que j'ai trouvé de plus proche serait IPC (InterProcess Communication)
Les IPC sous *NIX

Ce n'est pas la même chose, mais ça pourrait servir de couche sous jacente pour un protocol similaire, d'autant que tout comme pour COM, on peut faire du "IPC over network" ou encore "remote IPC"
Recherche Google sur le thème "remote IPC"

C'est vrai que c'est une chose qui manque à Linux, et c'est une bonne idée de se pencher sur la question.

Note: le support IPC est une option du kernel, qui peut éventuellement ne pas être présente sur certaines versions compilées avec l'option IPC désactivée.

Pourquoi ne pas tout simplement implémenter un protocol identique à OLE sous Linux ? Ce serait encore la meilleure solution....

Ma théorie sur l'abscence d'une telle fonctionnalité sous Linux/Unix, est que ces environnement n'ont pas tant mis l'accent sur l'interface utilisateur que l'a fait Windows, car OLE/DDE ont d'abord été inventés pour donner des fonctionnalités à l'interface utilisateur, avant d'être employés dérivatiement pour lier des composants entre-eux dans d'autres domaines.

[randriano]

Salut !

Pourquoi ne pas tout simplement implémenter un protocol identique à OLE sous Linux ? Ce serait encore la meilleure solution....

En effet, je pense aussi mais il faut reconnaître n'est pas un gros business comme Windows où des ingénieurs assez bien payés travaillent pour créer de telle technologie.

[gorgonite]

pourquoi ne pas utiliser CORBA ?
c'est un peu subtil à utiliser (enfin à apprendre ), mais une fois en main, c'est plus puissant que Com et DCom réunis

[randriano]

CORBA ? En effet, c'est subtile à apprendre : je croyais que CORBA et COM sont 2 technologies différentes au point de vue principe même.
Bon, je vais y jeter un coup d'oeil !

[Hibou57]

Une autre couche de base peut-être : « POSIX Message Queues »

Mais je ne connais pas, et je ne sais pas si ça peut servir à communiquer des données entre des processus.

Il faudrait également penser au "named pipe" (pour les données).

Avec un moyen de passer des messages et un moyen de passer des données, il doit bien y avoir moyen de faire quelque chose.

En tous cas, il faut définir un protocol, et ne pas faire du bricolage pour chaque application.

A défaut de savoir si OLE/DDE a un pendant sous Linux, une autre question serait : "existe t-il un projet en cours pour définir un protocol comparable à OLE/DDE sous Linux" ?

[granquet]

quand on me parle de DCOM/OLE/DDE etc ...
j'ai un peu de mal à visualiser ce que c'est (et à trouver une définition sur google)

pour OLE, il me semble (du temps ou je faisais un peu de visual basic) que ça permet d'intégrer des applications dans d'autres.
dans ce cas là, tu seras peut être intéressé par qt qui est très axés la dessus.

pour DCOM, il y'as CORBA (déjà cité)

et pour la DDE, aucune idée

[Hibou57]

dans ce cas là, tu seras peut être intéressé par qt qui est très axés la dessus

QT ne peut pas représenter une solution, parce que les personnes interessées par OLE ou DDE pourront ne pas être interessées par QT et éventuellement ne pas en vouloir. DDE était assez léger (ça fonctionnait sous Windows 3.1), alors que prendre QT pour obtenir cette seule fonctionnalité représente une solution lourde (même si sans rentrer dans les détails, je pense qu'il est tout de même préférable pour une UI de se baser sur QT que sur GTK).

En plus, Linux mettant l'accent sur la console, qui est une interface utilisateur suffisante pour bon nombre d'applications professionelles (ce qui ne doit pas être non-plus encore pretexte à ignorer ce qu'est un usage non-professionel), il faudrait qu'un tel système ne soit pas obligatoirement attaché à une interface graphique, mais soit une fonctionnalité des applications, indépendament de l'interface. On peut parfaitement imaginer par exemple des échanges de données ou d'objet entre des applications en mode console. Donc il faut séparer ce principe de l'interface utilisateur, et y voir plutôt une fonctionnalité abstraite.

Pour un aperçu de OLE FAQ à propos de OLE sur developpez.net. Mais ça ne parle que de OLE, et pas de DDE, qui est maintenant considéré comme obsolète (hérité de Windows 3.1)

[randriano]

QT ne peut pas représenter une solution, parce que les personnes interessées par OLE ou DDE pourront ne pas être interessées par QT et éventuellement ne pas en vouloir. DDE était assez léger (ça fonctionnait sous Windows 3.1), alors que prendre QT pour obtenir cette seule fonctionnalité représente une solution lourde (même si sans rentrer dans les détails, je pense qu'il est tout de même préférable pour une UI de se baser sur QT que sur GTK).

C'est vrai !!

Sur les trucs de IPC, ce n'est pas une équivalence car je pense que COM est loin d'être qu'un moyen de communiquer entre processus non ??

[randriano]

Je me suis un peu rafraichi en programmation système et je tire mes propres conclusions:
- le CORBA n'est pas l'équivalence pour COM qui est un modèle d'objets no réparti
- l'IPC huummm ce n'est pas vraiment un modèle mais seulement une technique qui peut utiliser le Socket/COM/RPC/messages

COM avec COM+ sont donc des solutions Microsoft qui n'ont pas encore vraiment d'égal, peut-être Java en a d'équivalent ou de plus puissant mais je ne sais pas

[Luc Hermitte]

CORBA est pour moi un équivalent des technos COM/DCOM de Microsoft pour le côté orienté composants distribués.

Dans les autres alternatives, il y a XPCOM (je crois) qui vient de mozilla. C'est du COM light.

Etant globalement déçu par CORBA (gérer les durées de vie des composants est un cauchemar en C++), je suis dans l'expectative d'une autre techno.

Michi Henning vante (évidemment) ICE comme un progrès par rapport à Corba, mais je n'ai pas encore eu le temps de m'y pencher. [Le monsieur est co-auteur du bouquin de référence sur le développement d'applis Corba en C++, et il impliqué dans ICE]



Sorti de ça, Linux a pour moi un problème : trop de NIH. A la différence Microsoft, où il y a (en gros) une voix unique qui dit : "ce sera ça, et comme ça.". Dans le monde *nix, on va se retrouver avec plein de projets différents et isolés qui feront des choses pas compatibles. Les composants orientés GUI (~ ActiveX) seront systématiquement dépendant de tel ou tel framework graphique. Sur cet aspect là, je considère que l'on n'est pas prêts de trouver un équivalent.

[randriano]

Bien expliqué Luc, merci