tunneling SSH ?
En quoi c'est standardisé ? C'est mis où dans la spec DBus qu'on pouvait en tant que client DBus déterminé la présence d'une couche de tunneling SSH pour que mon client s'adapte automatiquement ? C'est pas parcque t'utilises une couche de crypto qui utilise une technique d'encodage standardisé que ca devient une solution miracle : faut que le client dbus sache le consommer.
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
En quoi ca en fait un format standardisé tu m'expliques ? Moi je prends un framework quelconque, style Java ou .NET, non y'a rien pour consommer un service DBus de base, et pourtant ces framework en implémente des standards : faut utiliser une implémentation spécifique pour parler le langage de DBus : c'est un format certes documenté mais spécifique qui n'a rien de standard à l'heure actuelle.
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...
Ce qui est standard, c'est certaines couche de protocole associées à un formattage de données : exemple SOAP.
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
J'ai dis "une architecture similaire". C'est pas REST mais c'est non plus très loin. D'ailleur les 2 sont utilisés pour exposer des web-services.
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.
Si tu prends l'exemple des web-services ala SOAP : les données transitent en utilisant :
- une couche transport standardisé et largement répendue et implémentée : HTTP
- un format de données basé sur le méta-langage XML (encore une fois standardisé et largement répendu en terme d'implémentation).
- un format de description encore une fois basé sur XML (WSDL).
Bref, des technos extrêmement répendues, avec des libs et des outils existant dans la plupart des plateformes modernes : rien de tel pour l'interopérabilité. J'ajouterai que ces technos étant répendues et largment utilisé, il est extrêment facile de trouver documentation, développeurs et implémentations.
Alors voilà si demain je dois construire une plateforme avec un client, si je dois définir un protocole de communication pour exposer un service je fais quoi ? Je lui dis DBus ou Web-Services ? Lequel il risque d'être le plue à même de mettre en oeuvre rapidement sachant qu'il utilise l'OS le plus répendu du marché ?
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)
Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;) Ca n'a jamais marché pour autre chose que des traitement basique basés sur des flots texte. (ils ont oublié de chercher à standardiser le formattage d'objets plus complexes).
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
C'est vrai que tant que ce n'est pas une solution d'interopérabilité en dehors du petit monde du desktop unix, ca ne risque pas d'être une forte demande. Quoique on voit venir certaines tendances d'utilisation dans les dernières specs :
"the ANONYMOUS support means you can now use D-Bus (without a bus daemon) as a protocol for a network service provided to anonymous Internet or LAN clients "
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.
C'est pas forcement simple d'un point de vue fonctionnel, mais ca reste simple à utiliser. En fait tout dépend juste du problème que l'on cherche à adresser : les Web-Services rendent plus simple l'exposition de service à des plateformes hétérogènes et externes (typiquement techno cliente inconnue à travers Internet).
WCF rend plus simple l'écriture de service sans avoir à se préocuper du choix de la techno utilisé entre le consommateur du service et le composant qui l'expose.
DBus simplifie la communication entre process sur une même machine.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
Non, DBus n'ont pas atteind de juste milieu : ils partent justes de 2 postultats : on n'exposera jamais les services à travers internet (problème résolu par les web-services) et on part du principe que le consommateur du service va également utilisé DBus (problème résolu par WCF).
C'est pas un milieu, c'est une réponse à un autre problème.
Ça existe déjà. De manière SIMPLE et efficace
C'est pas dans les specs de base (l'introspection).
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 ?
Ca c'est les types de base, mais si on veut représenter par exemple une date ? Un type énuméré ? Voir plus compliqué ? Une url ? Y'a quoi pour spécifier de nouvaux formats ? Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
SSH. Pourquoi réinventer la roue, crévindiou ?
faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Ensuite SSH ne résoud pas tout : tu ne peux pas assurer la sécurité s'il y a des intermédiaire dans la délivrance des messages (genre t'as un proxy). Faut alors ajouter le cryptage dans la couche supérieur et plus sous la couche transport. Ca aussi ca se normalise (WS-Security pour les web-services).
<L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
/i>
C'était dans la suite logique de "exposer un service à internet".
Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
Et comment t'assures au milieu que tout est transactionnel ? Et là encore une fois, c'est toi qui a décidé de StartTransact et EndTransact : quand tout le monde aura comme toi réinventer la roue pour mettrte en oeuvre des opération atomiques à partir de plusieurs échanges de messages, certains vont se dire "et si on standardisait ca ?"
Au final, ça a donné les monstres de complexité que l'on connait.
? Le résultat est là : c'est extrêment simple à mettre en place, c'est très facile à consommer. Dessous la mécanique est lourde, ca a des conséquences en terme de perf, mais c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
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
Bof, ta définition du simple et fait "une et une seule chose" est facilement extensible dans le monde des web-services :
- TCP/IP fait une chose et le fait bien : assurer le transport d'une suite de données d'un point à un autre.
- HTTP ne fait qu'une chose et le fait bien : définir le protocole pour accéder à une ressource à partir d'une adresse unique. D'ailleur pour faire une seule chose, elle se base sur l'existant, une couche de transport existante (comme TCP/IP).
- XML fait une et une seule chose et le fait bien : définir une syntaxe générique pour d'autres langages. (en utilisant l'existant : les fichiers textes lisibles par les humains).
- SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message. D'ailleur pour faire une seule chose, SOAP se base sur l'existant pour la syntaxe (XML).
- WCF fait une seule chose et la fait bien : une couche d'abstraction entre la définition d'un service et les détails techniques de transport. Enfin l'objectif est de rendre la vie du développeur simple, ce à quoi aspire les couches d'abstraction généralement.
Les couches d'abstraction, c'est avant tout pour faire abstraction de problème qu'on a pas envie d'adresser : souvent des problèmes différents plus techniques. Parcque justement on veut se concentrer sur l'essentiel : le service offert, et pour le faire bien, rien de tel que de faire abstraction d'autres problématiques.
Regarde DBus, il cherche à adresser différentes problématique : encodage de message, formattage de données, simple appel RPC, messages, événements, etc.
Le seul vrai problème des abstractions, c'est la perte éventuelle de fonctionnalités (si l'abstraction cherche un dénominateur commun), et la lourdeur à l'exécution (il faut travers les couches).
C'est d'ailleur sans doute la première raison pour laquelle DBus n'utilise pas XML dans des messages textes par exemples : ils auraient pu s'appuyer sur l'existant mais pour des questions de perfs inter-process, rien ne vaut protocole optimisé pour les besoins que l'ont tente d'adresser.
Voilà, DBus c'est bien, mais ca remplace pas les Web-Services, et laisse ceux qui ont un doute sur la meilleure techno ajouter une couche d'abstraction qui leur évite de devoir faire un choix douloureux.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par TImaniac (site web personnel) . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 2.
En quoi c'est standardisé ? C'est mis où dans la spec DBus qu'on pouvait en tant que client DBus déterminé la présence d'une couche de tunneling SSH pour que mon client s'adapte automatiquement ? C'est pas parcque t'utilises une couche de crypto qui utilise une technique d'encodage standardisé que ca devient une solution miracle : faut que le client dbus sache le consommer.
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
En quoi ca en fait un format standardisé tu m'expliques ? Moi je prends un framework quelconque, style Java ou .NET, non y'a rien pour consommer un service DBus de base, et pourtant ces framework en implémente des standards : faut utiliser une implémentation spécifique pour parler le langage de DBus : c'est un format certes documenté mais spécifique qui n'a rien de standard à l'heure actuelle.
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...
Ce qui est standard, c'est certaines couche de protocole associées à un formattage de données : exemple SOAP.
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
J'ai dis "une architecture similaire". C'est pas REST mais c'est non plus très loin. D'ailleur les 2 sont utilisés pour exposer des web-services.
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.
Si tu prends l'exemple des web-services ala SOAP : les données transitent en utilisant :
- une couche transport standardisé et largement répendue et implémentée : HTTP
- un format de données basé sur le méta-langage XML (encore une fois standardisé et largement répendu en terme d'implémentation).
- un format de description encore une fois basé sur XML (WSDL).
Bref, des technos extrêmement répendues, avec des libs et des outils existant dans la plupart des plateformes modernes : rien de tel pour l'interopérabilité. J'ajouterai que ces technos étant répendues et largment utilisé, il est extrêment facile de trouver documentation, développeurs et implémentations.
Alors voilà si demain je dois construire une plateforme avec un client, si je dois définir un protocole de communication pour exposer un service je fais quoi ? Je lui dis DBus ou Web-Services ? Lequel il risque d'être le plue à même de mettre en oeuvre rapidement sachant qu'il utilise l'OS le plus répendu du marché ?
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)
Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;) Ca n'a jamais marché pour autre chose que des traitement basique basés sur des flots texte. (ils ont oublié de chercher à standardiser le formattage d'objets plus complexes).
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
C'est vrai que tant que ce n'est pas une solution d'interopérabilité en dehors du petit monde du desktop unix, ca ne risque pas d'être une forte demande. Quoique on voit venir certaines tendances d'utilisation dans les dernières specs :
"the ANONYMOUS support means you can now use D-Bus (without a bus daemon) as a protocol for a network service provided to anonymous Internet or LAN clients "
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.
C'est pas forcement simple d'un point de vue fonctionnel, mais ca reste simple à utiliser. En fait tout dépend juste du problème que l'on cherche à adresser : les Web-Services rendent plus simple l'exposition de service à des plateformes hétérogènes et externes (typiquement techno cliente inconnue à travers Internet).
WCF rend plus simple l'écriture de service sans avoir à se préocuper du choix de la techno utilisé entre le consommateur du service et le composant qui l'expose.
DBus simplifie la communication entre process sur une même machine.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
Non, DBus n'ont pas atteind de juste milieu : ils partent justes de 2 postultats : on n'exposera jamais les services à travers internet (problème résolu par les web-services) et on part du principe que le consommateur du service va également utilisé DBus (problème résolu par WCF).
C'est pas un milieu, c'est une réponse à un autre problème.
Ça existe déjà. De manière SIMPLE et efficace
C'est pas dans les specs de base (l'introspection).
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 ?
Ca c'est les types de base, mais si on veut représenter par exemple une date ? Un type énuméré ? Voir plus compliqué ? Une url ? Y'a quoi pour spécifier de nouvaux formats ? Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
SSH. Pourquoi réinventer la roue, crévindiou ?
faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Ensuite SSH ne résoud pas tout : tu ne peux pas assurer la sécurité s'il y a des intermédiaire dans la délivrance des messages (genre t'as un proxy). Faut alors ajouter le cryptage dans la couche supérieur et plus sous la couche transport. Ca aussi ca se normalise (WS-Security pour les web-services).
<L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
/i>
C'était dans la suite logique de "exposer un service à internet".
Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
Et comment t'assures au milieu que tout est transactionnel ? Et là encore une fois, c'est toi qui a décidé de StartTransact et EndTransact : quand tout le monde aura comme toi réinventer la roue pour mettrte en oeuvre des opération atomiques à partir de plusieurs échanges de messages, certains vont se dire "et si on standardisait ca ?"
Au final, ça a donné les monstres de complexité que l'on connait.
? Le résultat est là : c'est extrêment simple à mettre en place, c'est très facile à consommer. Dessous la mécanique est lourde, ca a des conséquences en terme de perf, mais c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
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
Bof, ta définition du simple et fait "une et une seule chose" est facilement extensible dans le monde des web-services :
- TCP/IP fait une chose et le fait bien : assurer le transport d'une suite de données d'un point à un autre.
- HTTP ne fait qu'une chose et le fait bien : définir le protocole pour accéder à une ressource à partir d'une adresse unique. D'ailleur pour faire une seule chose, elle se base sur l'existant, une couche de transport existante (comme TCP/IP).
- XML fait une et une seule chose et le fait bien : définir une syntaxe générique pour d'autres langages. (en utilisant l'existant : les fichiers textes lisibles par les humains).
- SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message. D'ailleur pour faire une seule chose, SOAP se base sur l'existant pour la syntaxe (XML).
- WCF fait une seule chose et la fait bien : une couche d'abstraction entre la définition d'un service et les détails techniques de transport. Enfin l'objectif est de rendre la vie du développeur simple, ce à quoi aspire les couches d'abstraction généralement.
Les couches d'abstraction, c'est avant tout pour faire abstraction de problème qu'on a pas envie d'adresser : souvent des problèmes différents plus techniques. Parcque justement on veut se concentrer sur l'essentiel : le service offert, et pour le faire bien, rien de tel que de faire abstraction d'autres problématiques.
Regarde DBus, il cherche à adresser différentes problématique : encodage de message, formattage de données, simple appel RPC, messages, événements, etc.
Le seul vrai problème des abstractions, c'est la perte éventuelle de fonctionnalités (si l'abstraction cherche un dénominateur commun), et la lourdeur à l'exécution (il faut travers les couches).
C'est d'ailleur sans doute la première raison pour laquelle DBus n'utilise pas XML dans des messages textes par exemples : ils auraient pu s'appuyer sur l'existant mais pour des questions de perfs inter-process, rien ne vaut protocole optimisé pour les besoins que l'ont tente d'adresser.
Voilà, DBus c'est bien, mais ca remplace pas les Web-Services, et laisse ceux qui ont un doute sur la meilleure techno ajouter une couche d'abstraction qui leur évite de devoir faire un choix douloureux.