Discussion :

[epsilon68]

Les sockets au lieu de COM ou DBus... mais bien sur
Je fais tous les jours du COM, et les sockets ne me viendraient meme pas a l'esprit ... sauf bien sur dans quelque ca particulier (1 fois en 7 ans).

faire des sockets au lieu de COM sur window, c'est vraiment faire un pas en arriere. COM est fait pour dialoguer avec des applications, d'ailleurs on a vu le BOUM des composants, mais on est en plein BOUM des applications utilisés comme des composants. Office, Photoshop, inDesign, RapidForm (CAO) sont quelques exemples de composant-application qu'on peut controler avec COM.
Utilise les sockets et personne n'utilisera ton appli, fais le avec COM et tu t'ouvres a une majorité d'utilisateurs potentiel soucieux de se coupler avec une autre application pour augmenter leur solution.

[epsilon68]

faire des sockets au lieu de COM sur window, c'est vraiment faire un pas en arriere. COM est fait pour dialoguer avec des applications, d'ailleurs on a vu le BOUM des composants, mais on est en plein BOUM des applications utilisés comme des composants. Office, Photoshop, inDesign, RapidForm (CAO) sont quelques exemples de composant-application qu'on peut controler avec COM.
Utilise les sockets et personne n'utilisera ton appli, fais le avec COM et tu t'ouvres a une majorité d'utilisateurs potentiels soucieux de se coupler avec une autre application pour augmenter leur solution.

(je voulais corriger une faute puis je me suis trompé de bouton et je ne m'en suis pas rendu compte)

[Jan Rendek]

Quand je veux synchroniser 2 processus, j'utilise un objet de synchro.
Quand je veux que deux processus s'échangent des infos j'utilise une techno pour ça: socket, pipes ou autre selon les contraintes.
Quand je veux faire une "application ouverte a une majorité d'utilisateurs potentiels soucieux de se coupler avec une autre application pour augmenter leur solution."
Alors je considèrerais COM.

Une appli, c'est d'abord un cahier des charges et des cas d'utilisation. Ensuite on décide. S'il existait un framework miracle pour tout faire cela se saurait.
Si tu penses que COM/DCOM est se framework miracle considère que je suis un sot borné et ne perd pas ton temps avec moi.

Cette discussion n'a que trop déviée. Je veux bien la poursuivre en MP, je ne pense pas qu'elle ait un interêt quelconque pour un lecteur potentiel.

[epsilon68]

Une appli, c'est d'abord un cahier des charges et des cas d'utilisation

oui c'est vrai on aurait du le poser au debut pour ensuite etre synchro (sans jeu de mots)

Quand je veux synchroniser 2 processus, j'utilise un objet de synchro.
Quand je veux que deux processus s'échangent des infos j'utilise une techno pour ça: socket, pipes ou autre selon les contraintes.
Quand je veux faire une "application ouverte a une majorité d'utilisateurs potentiels soucieux de se coupler avec une autre application pour augmenter leur solution." Alors je considèrerais COM.

peut etre que de choisir COM (ou autre DBUS) au debut permet a d'autre de l'utiliser pour des cas que tu ne pensais pas. C'est pour cela que je ne choisirais pas les sockets, beaucoup de travail (marshalling etc) pour finalement une solution fermée.

MAIS ca depend du cahier des charges, mais dans un cas general je choisirais COM

Si tu penses que COM/DCOM est se framework miracle considère que je suis un sot borné et ne perd pas ton temps avec moi.

Non COM n'est pas tout le temps adapté, tu as d'alleurs cité des exemples importants (mais que je trouve exceptionnel) ou maintenant pour des gros besoins de portabilité ...

... donc je ne pense pas que tu soit sot borné

Cette discussion n'a que trop déviée

Je suis d'accord, en plus on ne se convaincra pas, c'est a chacun de se faire son opinion.

a+