Ce que j'ai comparé: l'API dbus/python et WFC. Pas dbus et WFC. Parce que comme tu le dis si bien, les deux n'ont rien à voir: WFC n'est rien d'autre qu'une API.
Et j'ai dit que l'API de dbus/python était aussi souple et plus simple, donc plus "sexy" à mon gout (et j'ai admis que ça WFC pouvait aussi être vu comme sexy par ceux qui n'ont connu que SOAP et les DCOM/CORBA).
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). J'aimerais seulement réagir sur quelque points, je ne peux pas te maisser dire de telles choses sur DBus...
> - comment je gère le cryptage de mes services de manière standards ?
tunneling SSH ?
> Je dois me coltiner un format qui n'a rien de standard ?
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
Et pour WCF, seule l'API est peut être standard, j'en sais rien. Mais tu peux implémenter un protocole non standard au dessus de ça, donc bon...
> Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Rassure moi, tu t'es mal exprimé, hein ?
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
> Les web-services répondent à une problématique bien précise : l'inter-opérabilité
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
> DBus c'est de l'événementiel ultra-simple.
DBus n'est pas uniquement événementiel. Il peut être utilisé comme ça (cf HAL), mais ce n'est pas obligatoire (ce que KDE va en faire, en gros)
> Simple parcque tout jeune.
Non. DBus n'est déjà plus tout jeune. Il est simple parce qu'il est VOULU simple. Unix. KISS. Tout ce que les programmeurs Java/C# ont oubliés depuis longtemps, quoi (troll inside, don't feed the troll :p)
> Demain ils vont vouloir exposer des services à travers internet
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
> toute les couches d'abstraction qui vont bien
Trop d'abstraction tue la simplicité, l'efficacité et au final même la souplesse fini pa en pâtir. À faire trop d'abstractions, on en finit par oublier les problèmes réels.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
> ils vont vouloir ajouter de l'introspection
Ça existe déjà. De manière SIMPLE et efficace
> ils vont chercher à standardiser la façon d'échanger certains types de données
cf remarques précédentes. Encore une fois, tu as l'air de penser que les problèmes complexes nécessitent des solutions complexes. C'est complètement faux. Dans la plupart des cas, simplicité implique souplesse, et la souplesse permet de régler simplement des problèmes complexes.
Actuellement, tout peut être représenté avec DBus (il y a les nombres (de différents types)), les chaines de caractères, les tableaux, les structures et les tableaux associatifs. Qu'est ce qui ne peut pas être construit à partir de ça ?
> les normes de cryptage
SSH. Pourquoi réinventer la roue, crévindiou ?
> d'authentification
Tu n'as visiblement pas compris quels étaient les buts de DBus
L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
> de transaction
Je vois pas ce que tu veux dire là dedans... Dans le même sens que les transactions des BDD ? Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
> DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
C'est LE point central.
Toute l'histoire des web services, ça a été "on met tout dans le protocole afin de simplifier la vie au programmeur". Au final, ça a donné les monstres de complexité que l'on connait.
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN. Si ensuite, on voit qu'il y a des besoins communs à tous les utilisateurs, alors on fait une bibliothèque partagée "dbus-utils" qui s'en occupe. C'est par exemple le cas de l'introspection. Les specs du protocole n'en parlent même pas. À la place, tu as des fonctions pour l'introspection dans les libs et un document séparé disant que "l'introspection se fait par l'intermédiaire de org.freedesktop.DBus.Introspectable.Introspect dont voici les paramètres et ce que ça doit donner en sortie". De la même manière, les propriétés sont gérées par une interface org.freedesktop.DBus.Properties. Que tu ne trouveras jamais dans les specs
du protocole, parce que son boulot, c'est JUSTE du RPC.
C'est ça la souplesse et la modularité. C'est autre chose que les montagnes d'abstractions qu'on voit dans le monde Java/.NET
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 7.
Et j'ai dit que l'API de dbus/python était aussi souple et plus simple, donc plus "sexy" à mon gout (et j'ai admis que ça WFC pouvait aussi être vu comme sexy par ceux qui n'ont connu que SOAP et les DCOM/CORBA).
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). J'aimerais seulement réagir sur quelque points, je ne peux pas te maisser dire de telles choses sur DBus...
> - comment je gère le cryptage de mes services de manière standards ?
tunneling SSH ?
> Je dois me coltiner un format qui n'a rien de standard ?
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
Et pour WCF, seule l'API est peut être standard, j'en sais rien. Mais tu peux implémenter un protocole non standard au dessus de ça, donc bon...
> Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Rassure moi, tu t'es mal exprimé, hein ?
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
> Les web-services répondent à une problématique bien précise : l'inter-opérabilité
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
> DBus c'est de l'événementiel ultra-simple.
DBus n'est pas uniquement événementiel. Il peut être utilisé comme ça (cf HAL), mais ce n'est pas obligatoire (ce que KDE va en faire, en gros)
> Simple parcque tout jeune.
Non. DBus n'est déjà plus tout jeune. Il est simple parce qu'il est VOULU simple. Unix. KISS. Tout ce que les programmeurs Java/C# ont oubliés depuis longtemps, quoi (troll inside, don't feed the troll :p)
> Demain ils vont vouloir exposer des services à travers internet
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
> toute les couches d'abstraction qui vont bien
Trop d'abstraction tue la simplicité, l'efficacité et au final même la souplesse fini pa en pâtir. À faire trop d'abstractions, on en finit par oublier les problèmes réels.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
> ils vont vouloir ajouter de l'introspection
Ça existe déjà. De manière SIMPLE et efficace
> ils vont chercher à standardiser la façon d'échanger certains types de données
cf remarques précédentes. Encore une fois, tu as l'air de penser que les problèmes complexes nécessitent des solutions complexes. C'est complètement faux. Dans la plupart des cas, simplicité implique souplesse, et la souplesse permet de régler simplement des problèmes complexes.
Actuellement, tout peut être représenté avec DBus (il y a les nombres (de différents types)), les chaines de caractères, les tableaux, les structures et les tableaux associatifs. Qu'est ce qui ne peut pas être construit à partir de ça ?
> les normes de cryptage
SSH. Pourquoi réinventer la roue, crévindiou ?
> d'authentification
Tu n'as visiblement pas compris quels étaient les buts de DBus
L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
> de transaction
Je vois pas ce que tu veux dire là dedans... Dans le même sens que les transactions des BDD ? Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
> DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
C'est LE point central.
Toute l'histoire des web services, ça a été "on met tout dans le protocole afin de simplifier la vie au programmeur". Au final, ça a donné les monstres de complexité que l'on connait.
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN. Si ensuite, on voit qu'il y a des besoins communs à tous les utilisateurs, alors on fait une bibliothèque partagée "dbus-utils" qui s'en occupe. C'est par exemple le cas de l'introspection. Les specs du protocole n'en parlent même pas. À la place, tu as des fonctions pour l'introspection dans les libs et un document séparé disant que "l'introspection se fait par l'intermédiaire de org.freedesktop.DBus.Introspectable.Introspect dont voici les paramètres et ce que ça doit donner en sortie". De la même manière, les propriétés sont gérées par une interface org.freedesktop.DBus.Properties. Que tu ne trouveras jamais dans les specs
du protocole, parce que son boulot, c'est JUSTE du RPC.
C'est ça la souplesse et la modularité. C'est autre chose que les montagnes d'abstractions qu'on voit dans le monde Java/.NET