Comment fait HTTP, selon toi ? C'est écrit en dur dans la RFC 2616 ?
C'est décrit dans la RFC 2818 du HTTPS. Bref c'est décrit de manière formelle. L'uri te donne l'information sur le protocole utilisé, ce qui permet au client de s'adapter.
Bref, il suffit pas de dire "bah y'a qu'à faut que", c'est justement la valeur ajoutée de toutes les specs autour des web-services (les WS-*), plutôt que de supposer que c'est telle méthode qu'il faut utiliser, c'est écrit noir sur blanc pour que la technique de mise en oeuvre soit relativement standard.
mais "on peut faire sans complexifier la spec"
Certes, mais à l'heure actuelle ce n'est pas le cas.
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
y'a standard au sens : "normalisé par un consortium" type W3C
et standard an sens : "standard de fait largement répendu et implémenté"
Le fait est que DBus n'est pas répendu et encore moins normalisé. Et il ne s'appui pas sur les standards de formattage existant dans les plateformes les plus répendues. Bref, à implémenter, c'est pas "simple".
De la différence entre le fond et la forme...
Oué mais cette philosophie m'énerve au plus haut point, elle sert de prétexte pour descendre des gros frameworks, comme si "gros" != simple. Le tout est de savoir aggréger des composants simple pour proposer un ensemble de fonctionnalités cohérente. Se contenter de fournir les briques simples, c'est aussi s'assurer de réinventer la roue.
timestamp ? RFC 822 ?
Et c'est écrit où dans la spec qu'il faut utiliser cette norme ? Nan parcque justement voilà : les specs c'est conçu pour écrire noir sur blanc ce qui te paraît évident. Ensuite si ce type n'est pas défini de base, comment vais-je le reconnaître par introspection s'il est sérialisé dans une chaîne de caractère ?
Tu parles des "enum" du C ? un entier suffit largement...
Et je la met où l'information pour le consommateur du service que 1 = Stopped, 2 = Running, 3 = Unknown ?
Comment le client découvre cette information ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
De complexité ?? C'est mal de vouloir dire que ne sont acceptés que les entiers entre 1 et 100 parcqu'on veut un pourcentage dans le message ?
Comment tu vas faire en DBus ? Tu vas l'écrire dans la documentation pour le développeur. Des gens se sont dit : tiens si on formalisait ces contraintes, pour que la validation soit automatique et le contenu auto-descriptif ? Ca éviterait les erreurs d'interprétation et les méthodes de validations aléatoires.
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par
Toi tu proposes à la place d'over-bloater toutes les docs avec ces infos. Obligatoires parcque justement non standardisé. Avec les risques d'interprétation divergents. Et l'impossibilité pour les frameworks de proposer des facitilités associées.
juste pour ça ?
C'est pour ne pas réinventer la roue. Ca s'appelle des normes, des standards, des RFC, des patterns, ce que tu veux, l'objectif est toujours le même : formaliser des pratiques courantes pour faciliter la vie de tout le monde.
On peut le standardiser de la même manière que l'introspection...
Tout a fait. Et faut le faire. Et c'est pour ca que les web-services te paraissent un gros bloat. Juste parcqu'ils formalisent ce que tout le monde réinvente dans son coin en DBus ?
Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
Les types de base si. Pour les autres types, DBus doit fournir un cadre assez ouvert pour pouvoir exprimer des nouveaux types. Ils auraient par exemple pu s'appuyer sur les nombreux formats existant style XSD ou autre Relax-NG par exemple. Non, ils condamnent les développeurs à rédiger des docs avec toutes les erreurs potentielles d'interprétations et de réinventage de roue qui vont bien avec.
XML-RPC, du temps ou je l'ai vu, avait une spec de deux pages. Il ne nécessitait aucun outillage étrange de génération d'interfaces qui lui même génère des source qui génèrent..., et était entièrement implémentable en moins d'une journée avec l'aide d'une bonne lib XML
Tu vois, XML est pourtant une norme de plus de 2 pages : mais ils réutilisent une spec de mise en forme de données plutôt que de réinventer la roue comme le fait DBus. Puis les gens se sont dit : c'est gentil, mais ca suffit pas, on bloat la doc, on réinvente à chaque fois la roue, faut normaliser la façon de décrire les données qui passent dans un service XML-RPC, etc.
Pourrais tu t'en sortir sans la grosse artillerie d'IDEs, d'aides au dévellopement, d'aide aux outils de dev, d'aide aux outils d'aides aux outils de dev... ?
Et ? Ces outils existent. SOAP a même été conçu pour que ces outils automatiques existent : mais pour cela ca supposait de formaliser un maximum de chose pour pouvoir automatiser.
Pour finir, même si tu as des outils qui te cachent la saleté sous le tapis, qu'est-ce que tu fais quand ils te lachent ? Si tu veux les débugger ?
C'est pour ca entre autre que SOAP utilise HTTP/XML : c'est facile à interpréter par un humain en mode texte.
Le but, c'est de pisser du code sans vraiment comprendre ce qui se passe en interne ou de faire quelque chose de relativement sûr qui ne donne pas de surprises ?
Le but, c'est que le framework "pisse" de manière standard tout le code dont je n'ai pas besoin, pour me faciliter la vie à moi développeur. Bref, que je n'ai pas besoin de réinventer la roue.
Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
L'avantage, c'est que c'est en standard dans le framework, donc largement éprouvé et écrit par des gens plus compétent que moi. Alors oui si y'a un bug c'est la merde. Mais dans la réalité j'ai jamais eu de problème :) Et puis y'a des implémentations libres hein, avec le code source ;) Et puis ca s'appui sur des technos simples et matures (XML & co).
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Ca ce sont d'autres specs séparées justement. Mais explicitement destinée à être utilisé avec les web-services.
C'est visiblement le cas de SOAP
Bah DBus gre :
- une couche de transport de messages
- la définition des messages
- le formattage des messages
Ca pourrait être très bien séparé, et ils auraient pu réutiliser l'existant, notamment le formattage.
Faut pas déconner, XML n'est pas LA solution universelle.
Oui c'est pour ca que j'ai dit que dans DBus c'était pas pertinent. Mais ca n'empêche pas qu'il existe d'autres standards de formattage déjà normalisés qu'ils auraient pu réutiliser plutôt que réinventer la roue.
C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ?
Parcque l'ASCII ne te dit pas comment formatter des données. Elle te dit juste comment passer une suite de caractères, une structure plate. Tout le monde est amené tôt ou tard à passer des données structurées plus complexes (tableau, arbre, objet, etc.) : et là faut mieux avoir une grammaire bien clairement définie. Et autant réutiliser l'existant.
Encore une fois, les web-services c'est pas la panacé, mais ca a l'avantage d'utiliser des standards ouverts largement implémentés, de proposer un contenu auto-descriptif autant que possible, avec un ensemble de specs additionnelles pour formaliser les pratiques les plus courantes : rien de tel pour l'interopérabilité.
Pour le reste y'a RMI, .NET remoting ou DBus (qui est très bien pour ce pour quoi il est utilisé).
[^] # 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.
C'est décrit dans la RFC 2818 du HTTPS. Bref c'est décrit de manière formelle. L'uri te donne l'information sur le protocole utilisé, ce qui permet au client de s'adapter.
Bref, il suffit pas de dire "bah y'a qu'à faut que", c'est justement la valeur ajoutée de toutes les specs autour des web-services (les WS-*), plutôt que de supposer que c'est telle méthode qu'il faut utiliser, c'est écrit noir sur blanc pour que la technique de mise en oeuvre soit relativement standard.
mais "on peut faire sans complexifier la spec"
Certes, mais à l'heure actuelle ce n'est pas le cas.
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
y'a standard au sens : "normalisé par un consortium" type W3C
et standard an sens : "standard de fait largement répendu et implémenté"
Le fait est que DBus n'est pas répendu et encore moins normalisé. Et il ne s'appui pas sur les standards de formattage existant dans les plateformes les plus répendues. Bref, à implémenter, c'est pas "simple".
De la différence entre le fond et la forme...
Oué mais cette philosophie m'énerve au plus haut point, elle sert de prétexte pour descendre des gros frameworks, comme si "gros" != simple. Le tout est de savoir aggréger des composants simple pour proposer un ensemble de fonctionnalités cohérente. Se contenter de fournir les briques simples, c'est aussi s'assurer de réinventer la roue.
timestamp ? RFC 822 ?
Et c'est écrit où dans la spec qu'il faut utiliser cette norme ? Nan parcque justement voilà : les specs c'est conçu pour écrire noir sur blanc ce qui te paraît évident. Ensuite si ce type n'est pas défini de base, comment vais-je le reconnaître par introspection s'il est sérialisé dans une chaîne de caractère ?
Tu parles des "enum" du C ? un entier suffit largement...
Et je la met où l'information pour le consommateur du service que 1 = Stopped, 2 = Running, 3 = Unknown ?
Comment le client découvre cette information ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
De complexité ?? C'est mal de vouloir dire que ne sont acceptés que les entiers entre 1 et 100 parcqu'on veut un pourcentage dans le message ?
Comment tu vas faire en DBus ? Tu vas l'écrire dans la documentation pour le développeur. Des gens se sont dit : tiens si on formalisait ces contraintes, pour que la validation soit automatique et le contenu auto-descriptif ? Ca éviterait les erreurs d'interprétation et les méthodes de validations aléatoires.
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par
Toi tu proposes à la place d'over-bloater toutes les docs avec ces infos. Obligatoires parcque justement non standardisé. Avec les risques d'interprétation divergents. Et l'impossibilité pour les frameworks de proposer des facitilités associées.
juste pour ça ?
C'est pour ne pas réinventer la roue. Ca s'appelle des normes, des standards, des RFC, des patterns, ce que tu veux, l'objectif est toujours le même : formaliser des pratiques courantes pour faciliter la vie de tout le monde.
On peut le standardiser de la même manière que l'introspection...
Tout a fait. Et faut le faire. Et c'est pour ca que les web-services te paraissent un gros bloat. Juste parcqu'ils formalisent ce que tout le monde réinvente dans son coin en DBus ?
Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
Les types de base si. Pour les autres types, DBus doit fournir un cadre assez ouvert pour pouvoir exprimer des nouveaux types. Ils auraient par exemple pu s'appuyer sur les nombreux formats existant style XSD ou autre Relax-NG par exemple. Non, ils condamnent les développeurs à rédiger des docs avec toutes les erreurs potentielles d'interprétations et de réinventage de roue qui vont bien avec.
XML-RPC, du temps ou je l'ai vu, avait une spec de deux pages. Il ne nécessitait aucun outillage étrange de génération d'interfaces qui lui même génère des source qui génèrent..., et était entièrement implémentable en moins d'une journée avec l'aide d'une bonne lib XML
Tu vois, XML est pourtant une norme de plus de 2 pages : mais ils réutilisent une spec de mise en forme de données plutôt que de réinventer la roue comme le fait DBus. Puis les gens se sont dit : c'est gentil, mais ca suffit pas, on bloat la doc, on réinvente à chaque fois la roue, faut normaliser la façon de décrire les données qui passent dans un service XML-RPC, etc.
Pourrais tu t'en sortir sans la grosse artillerie d'IDEs, d'aides au dévellopement, d'aide aux outils de dev, d'aide aux outils d'aides aux outils de dev... ?
Et ? Ces outils existent. SOAP a même été conçu pour que ces outils automatiques existent : mais pour cela ca supposait de formaliser un maximum de chose pour pouvoir automatiser.
Pour finir, même si tu as des outils qui te cachent la saleté sous le tapis, qu'est-ce que tu fais quand ils te lachent ? Si tu veux les débugger ?
C'est pour ca entre autre que SOAP utilise HTTP/XML : c'est facile à interpréter par un humain en mode texte.
Le but, c'est de pisser du code sans vraiment comprendre ce qui se passe en interne ou de faire quelque chose de relativement sûr qui ne donne pas de surprises ?
Le but, c'est que le framework "pisse" de manière standard tout le code dont je n'ai pas besoin, pour me faciliter la vie à moi développeur. Bref, que je n'ai pas besoin de réinventer la roue.
Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
L'avantage, c'est que c'est en standard dans le framework, donc largement éprouvé et écrit par des gens plus compétent que moi. Alors oui si y'a un bug c'est la merde. Mais dans la réalité j'ai jamais eu de problème :) Et puis y'a des implémentations libres hein, avec le code source ;) Et puis ca s'appui sur des technos simples et matures (XML & co).
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Ca ce sont d'autres specs séparées justement. Mais explicitement destinée à être utilisé avec les web-services.
C'est visiblement le cas de SOAP
Bah DBus gre :
- une couche de transport de messages
- la définition des messages
- le formattage des messages
Ca pourrait être très bien séparé, et ils auraient pu réutiliser l'existant, notamment le formattage.
Faut pas déconner, XML n'est pas LA solution universelle.
Oui c'est pour ca que j'ai dit que dans DBus c'était pas pertinent. Mais ca n'empêche pas qu'il existe d'autres standards de formattage déjà normalisés qu'ils auraient pu réutiliser plutôt que réinventer la roue.
C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ?
Parcque l'ASCII ne te dit pas comment formatter des données. Elle te dit juste comment passer une suite de caractères, une structure plate. Tout le monde est amené tôt ou tard à passer des données structurées plus complexes (tableau, arbre, objet, etc.) : et là faut mieux avoir une grammaire bien clairement définie. Et autant réutiliser l'existant.
Encore une fois, les web-services c'est pas la panacé, mais ca a l'avantage d'utiliser des standards ouverts largement implémentés, de proposer un contenu auto-descriptif autant que possible, avec un ensemble de specs additionnelles pour formaliser les pratiques les plus courantes : rien de tel pour l'interopérabilité.
Pour le reste y'a RMI, .NET remoting ou DBus (qui est très bien pour ce pour quoi il est utilisé).