> 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.
Comment fait HTTP, selon toi ? C'est écrit en dur dans la RFC 2616 ?
Ce que je voulais dire par "SSH" c'est pas "on fait un hack quick & dirty" mais "on peut faire sans complexifier la spec"
> 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
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
> C'est pas REST mais c'est non plus très loin.
Mais c'est qu'il récidive, le bougre :)
SOAP se traine vaguement au dessus d'un protocole de type REST comme un boulet au pied pour des raisons pratiques (HTTP, ça passe partout). La comparaison s'arrête là. SOAP, c'est du RPC, l'opposé de REST (dans les longs trolls du moins :p)
> Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;)
De la différence entre le fond et la forme...
> Ca c'est les types de base, mais si on veut représenter par exemple
> une date
timestamp ? RFC 822 ?
Encore une fois, tu crois qu'ils font comment, pour HTTP ? Ils définissent un type date, ou ils disent simplement "une date sera formatée comme défini dans la RFC xxx ou yyy, au choix. Toute autre date est indéfinie"
> Un type énuméré ?
Tu parles des "enum" du C ? un entier suffit largement...
> Une url ?
Comme tout le monde, par une chaine de caractères ?
> Y'a quoi pour spécifier de nouvaux formats ?
> Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
> Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
C'est si difficile que ça de se mettre d'accord entre devs ? (dans la doc technique, à tout hasard)
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par: les 397 moyens de passer par HTTP GET, HTTP POST, HTTP PUT, HTTP DELETE, FTP, SMTP, IPoT, l'authentification, la cryptholographie, la numérologie, la redundanc-scalability, 965 définitions de type (URL, Date, Path, Port, Range, Domain, User, Password, Service, ServiceInfo, ServiceInfoServer, ServiceInfoServerInfo, Toto, Tata, Tutu, Titi, Rominet) juste pour ça ?
> faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Non. Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
> 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 ?"
On peut le standardiser de la même manière que l'introspection...
Et l'implémenter de la même manière...
> c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
Non, c'est lié à la surcomplexification.
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
Dis moi, la spec de SOAP: combien de pages ? 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... ? Combien de temps pour implémenter complètement les specs (même de manière quick & dirty) ? Pour quel apport, finalement, par rapport à XML-RPC ?
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 ?
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 ?
Si demain, ton application se met à merder après recompilation alors que tu n'as modifié que les commentaires, tu accuses qui ? Ton code ? Ou une des 360000 lignes autogénérées ? Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
Ce n'est pas parce que ça "parait" simple que "c'est" simple. Cacher la complexité derrière du code auto généré, c'est un peu comme la politique de l'autruche, ça ne résoud pas les vrais problèmes.
C'est de ce juste milieu que je parlais. Effectivement, c'est plus contre SOAP que contre WCF, je te l'accorde ;)
> SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message.
Non. SOAP permet de faire
- du passage de messages
- de définition de messages
- de validation de messages
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Avec chacun de ces points tellement complexe qu'il meriterait une spec à lui seul.
Faire une seule chose, c'est faire une seule chose simple, sinon c'est qu'on pouvait décomposer la chose en sous problèmes indépendants. C'est visiblement le cas de SOAP (pas de WCF, je te l'accorde, mais cf une citation précédente: "piling complexity...")
> 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.
Tu es de ceux qui pensent que HTTP devrait être réécrit en XML ?
Faut pas déconner, XML n'est pas LA solution universelle. Même s'il est adapté dans la très grande majorité des cas, la non utilisation de XML n'est pas forcément un pis-aller. SMTP, HTTP & co se basent sur l'existant: l'ASCII. C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ? Pour avoir le plaisir de dire "yeah, moi je suis xml-compliant" ?
[^] # 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é à 3.
Comment fait HTTP, selon toi ? C'est écrit en dur dans la RFC 2616 ?
Ce que je voulais dire par "SSH" c'est pas "on fait un hack quick & dirty" mais "on peut faire sans complexifier la spec"
> 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
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
> C'est pas REST mais c'est non plus très loin.
Mais c'est qu'il récidive, le bougre :)
SOAP se traine vaguement au dessus d'un protocole de type REST comme un boulet au pied pour des raisons pratiques (HTTP, ça passe partout). La comparaison s'arrête là. SOAP, c'est du RPC, l'opposé de REST (dans les longs trolls du moins :p)
> Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;)
De la différence entre le fond et la forme...
> Ca c'est les types de base, mais si on veut représenter par exemple
> une date
timestamp ? RFC 822 ?
Encore une fois, tu crois qu'ils font comment, pour HTTP ? Ils définissent un type date, ou ils disent simplement "une date sera formatée comme défini dans la RFC xxx ou yyy, au choix. Toute autre date est indéfinie"
> Un type énuméré ?
Tu parles des "enum" du C ? un entier suffit largement...
> Une url ?
Comme tout le monde, par une chaine de caractères ?
> Y'a quoi pour spécifier de nouvaux formats ?
> Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
> Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
C'est si difficile que ça de se mettre d'accord entre devs ? (dans la doc technique, à tout hasard)
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par: les 397 moyens de passer par HTTP GET, HTTP POST, HTTP PUT, HTTP DELETE, FTP, SMTP, IPoT, l'authentification, la cryptholographie, la numérologie, la redundanc-scalability, 965 définitions de type (URL, Date, Path, Port, Range, Domain, User, Password, Service, ServiceInfo, ServiceInfoServer, ServiceInfoServerInfo, Toto, Tata, Tutu, Titi, Rominet) juste pour ça ?
> faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Non. Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
> 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 ?"
On peut le standardiser de la même manière que l'introspection...
Et l'implémenter de la même manière...
> c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
Non, c'est lié à la surcomplexification.
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
Dis moi, la spec de SOAP: combien de pages ? 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... ? Combien de temps pour implémenter complètement les specs (même de manière quick & dirty) ? Pour quel apport, finalement, par rapport à XML-RPC ?
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 ?
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 ?
Si demain, ton application se met à merder après recompilation alors que tu n'as modifié que les commentaires, tu accuses qui ? Ton code ? Ou une des 360000 lignes autogénérées ? Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
Ce n'est pas parce que ça "parait" simple que "c'est" simple. Cacher la complexité derrière du code auto généré, c'est un peu comme la politique de l'autruche, ça ne résoud pas les vrais problèmes.
C'est de ce juste milieu que je parlais. Effectivement, c'est plus contre SOAP que contre WCF, je te l'accorde ;)
> SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message.
Non. SOAP permet de faire
- du passage de messages
- de définition de messages
- de validation de messages
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Avec chacun de ces points tellement complexe qu'il meriterait une spec à lui seul.
Faire une seule chose, c'est faire une seule chose simple, sinon c'est qu'on pouvait décomposer la chose en sous problèmes indépendants. C'est visiblement le cas de SOAP (pas de WCF, je te l'accorde, mais cf une citation précédente: "piling complexity...")
> 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.
Tu es de ceux qui pensent que HTTP devrait être réécrit en XML ?
Faut pas déconner, XML n'est pas LA solution universelle. Même s'il est adapté dans la très grande majorité des cas, la non utilisation de XML n'est pas forcément un pis-aller. SMTP, HTTP & co se basent sur l'existant: l'ASCII. C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ? Pour avoir le plaisir de dire "yeah, moi je suis xml-compliant" ?