Articles précédents : Interview
- [72] Firefox : Entretien avec la présidente de la Mozilla Foundation
- [17] Entretien avec Samuel Hocevar, Chef du projet Debian
- [3] Chat 01net « Les logiciels libres » jeudi 22 mars 2007 de 18h à 19h
- [7] Interview de Marc Schneider, fondateur du projet openaguila.org
- [6] Enquête entreprise utilisant du libre dans ses offres commerciales
- [11] « Où en est l'économie du Logiciel Libre », podcast ZDNet.fr
- [56] Interview de G. Collomb, Sénateur-Maire de Lyon
- [0] FOSDEM : Seconde série d'interviews
- [82] Richard Cazenave apporte quelques précisions sur la migration de l'Assemblée Nationale vers Linux
- [160] Entretien avec Richard Stallman au sujet des DRMs
Liens connexes
- 5mn avec Miguel de Icaza : Miguel fait une démonstration de Silverlight pour Linux (4587 hits)
- Implementing Silverlight in 21 Days (blog de Miguel) (883 hits)
- Moonlight (1185 hits)
- DLFP : Mono projette l'implémentation de Silverlight de Microsoft (395 hits)
- Journal DLFP sur Moonlight (341 hits)
Dépêche modérée par
Dépêche éditée par
Interview : Miguel de Icaza fait une démonstration de Moonlight
Posté par Didier Girard. Modéré le 25 juin 2007.
La semaine dernière, après 21 jours de développement, Miguel venait présenter à Paris le résultat du travail de son équipe. Ce que ces sept développeurs ont réalisé est tout simplement impressionnant. D'après Miguel, il s'agit de la séance de programmation la plus intense qu'il ait jamais réalisée.
J'ai profité de son passage à Paris pour réaliser un entretien vidéo en français de Miguel permettant de voir un aperçu du résultat.
![[fr]](../../../images/fr.png)
5mn avec Miguel de Icaza : Miguel fait une démonstration de Silverlight pour Linux (4587 hits)![[en]](../../../images/en.png)
Implementing Silverlight in 21 Days (blog de Miguel) (883 hits)-
Moonlight (1185 hits)
-
DLFP : Mono projette l'implémentation de Silverlight de Microsoft (395 hits)
-
Journal DLFP sur Moonlight (341 hits)
> Lire la dépêche (62 commentaires, moyenne: 2,7).
Microsoft comprend enfin l'intérêt du Libre
Ils sont vraiment fort chez Microsoft :
Microsoft passe des accords avec de grosses boites du Libre.
Microsoft sort une technologie .
Microsoft annonce que cette technologie sera peut être fonctionnel sur d'autre OS que Windows.
Microsoft attend que la communauté ou qu'une des boites avec lesquelles il a passé des accords fasse le portage à sa place.
Passez à la caisse, chez Microsoft bien sur ;)
Cela à pleins d'avantages :
Leur technologie fonctionne mais Microsoft ne le supporte pas officiellement comme ça au moindre problème hop ! C'est pas leur faute.
Si c'est une boite qui s'occupe du portage c'est encore mieux : elle se décridibilise à chaque pépin et deviens la bête noir de la communauté (GPLv3 - Novell)
La communauté/la boite bosse gratuitement pour Microsoft.
Le temps passé au portage, maintient du code...c'est du temps non utilisé pour une solution alternative.
Du fait du portage et du soutiens d'une grosse entreprise du Libre la technologie Microsoft est de plus en plus utilisée (Internet Explorer Inside).
Microsoft refait une santé à son image.
On peut pas leur enlever ça : y'a pas à dire, ils son vraiment malins chez Microsoft.
Préparez la vaseline.
-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par snt () le 25/06/2007 à 11:45. (lien). Évalué à -6.>La communauté/la boite bosse gratuitement
t'es nouveau ici ?-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Pinaraf (Jabber id, ) le 25/06/2007 à 11:54. (lien). Évalué à 10.Il a dit "pour microsoft", que l'on peut interpréter comme étant "du point de vue de microsoft" ou "au service de microsoft".
Si on prend le point de vue de microsoft, il est clair que la boîte et la communauté bossent gratos...
De toute façon .net ça pue, comme XP...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Plop () le 25/06/2007 à 12:25. (lien). Évalué à 4.>De toute façon .net ça pue
On ne peut que s'incliner devant ton avis argumenté.
Perso, je trouve .Net intéressant parce que :
+ La VM permet d'utiliser plusieurs langages. Une classe C# est compatible binairement avec du VB ou du C++.
+ La gestion des modules avec signature cryptologique forte.
+ La séparation des privilèges d'unappli .Net est très intéressante. Ainsi, on peut exécuter une appli en l'empêchant d'accéder aux ressources locals (disque dur, réseau...) Il est possible ainsi de sécuriser un code avec une granulométrie qui est celle d'une méthode
+ Un framework vraiment complet et homogène. Là ou avant, il fallait utiliser les win32 API plus ou moins merdiques.
+ L'intégration et la simplicité de développement des webs services.
+ Du code autogénéré enfin lisible. (Pas comme ces merdes ATL ou MFC)
+ Les déploiements xcopy
Les points négatifs maintenant
- Perte de rapidité d’exécution
- les brevets sur la partie System.Forms
- L'aide, je crois que tout le monde est d'accord pour la trouver mal organisé.
Oui, Java ou python permet d'avoir plusieurs de ces qualités, mais pas toutes.
.Net est intéressant et mettre la tête dans le sable n'est pas le meilleur moyen de s'en rendre compte.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Pinaraf (Jabber id, ) le 25/06/2007 à 12:40. (lien). Évalué à 10.Ouais.
Moi je reste campé sur le C++ (avec Qt4), Java ou Python... Les goûts et les couleurs quoi : je vois rien d'intéressant dans .net pour mes usages, et Java fait tout ce qui me semble potentiellement intéressant dans ta liste...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Raphaël Gertz (page perso, ) le 25/06/2007 à 13:46. (lien). Évalué à 7.Tu oublie php dans la liste quand même...
On peux faire des choses sacrément jolies avec
(et non on ne peux pas faire que des sites pouris passoire avec)
Je suis en train d'en manger a longueur de journée en ce moment et j'ai découvert pas mal de choses...
Notement les classes MDB2 (gestion de base de donnée), QuickForm et consort.
Avec vous arrivez assez rapidement a des résultats fonctionnel impressionnant.
Bon en revanche, le gros point noir reste encore les classes pear non migré en php5 E_STRICT.
Petit rappel, si votre site ne passe pas en :
error_reporting(E_ALL|E_STRICT);
Pas la peine de faire du php, vous allez ouvrir des trous de sécurités dans tous les sens...
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 13:04. (lien). Évalué à 2.> + La gestion des modules avec signature cryptologique forte.
> + La séparation des privilèges d'unappli .Net est très intéressante. Ainsi, on peut exécuter une appli en l'empêchant d'accéder aux ressources locals (disque dur, réseau...) Il est possible ainsi de sécuriser un code avec une granulométrie qui est celle d'une méthode
Et dire que certains osent mettre ça dans les avantages...
> + L'intégration et la simplicité de développement des webs services.
Rassure moi, c'était une farce ? hein ?-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par el_mickey () le 25/06/2007 à 13:14. (lien). Évalué à 1.>>Rassure moi, c'était une farce ? hein ?
Euh tu peux argumenter s'il te plait ? Pärce que si il y a bien un truc simple avec .Net c'est ça, cf WCF.-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 13:22. (lien). Évalué à 4.http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-(...)
-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par el_mickey () le 25/06/2007 à 13:34. (lien). Évalué à -1.Ouai la tu critiques la technologie en elle même. Et non pas la facilié d'intégration à .Net.
Enfin bon WCF : http://www.microsoft.com/france/msdn/netframework/3/wcf/intr(...) , si tu arrives a dire que c'est pas sexy comme idée...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 14:08. (lien). Évalué à 6.J'ai peur de me répéter: c'est une blague ?
Vraiment, oui, ça a l'air très intéressant... pour le programmeur payé à la ligne de code (pour l'employeur, moins, mais les commerciaux sont là pour le convaincre que plus c'est lourd, mieux c'est)
Après avoir lu cet article, je ne peux pas m'empêcher de citer Rich Felker:
"Piling more complexity on top of mistaken complexity is not a solution. It's pure stupidity"
Honnêtement, où est l'idée sexy là dedans ? Je ne vois qu'un moyen BEAUCOUP plus compliqué (doux euphémisme) de faire ce que DCOP/DBUS font depuis des années. Ça n'apporte rien, à part quelques buzwords à ajouter au dictionnaire (ou peut être pas en fait, mon dictionnaire de buzzwords est très vieux...)
Non, sérieusement, si tu pouvais me dire ce qu'il y a de sexy là dedans, ce serait gentil, parce que là, j'ai vraiment l'impression d'avoir loupé quelque chose...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo le Clown () le 25/06/2007 à 14:28. (lien). Évalué à 6.On ne peut s'empêcher de répondre à ce bon monsieur
"Et comment fait on lorsqu'il n'y a pas qu'une seule technologie à interconnecter ?".
Tu nous cites l'exemple DCOP /DBUS mais comment font ils pour communiquer avec du pur CORBA ou encore du DCOM.
Doit-on développer des ponts dans tous les sens avec toutes les technos existantes ou définir un standard, une couche supplémentaire vers laquelle chacune des technologies pourra s'interconnecter ?
Ce modèle en couche que tu critiques a pourtant permis de belles avancées comme la venue de l'internet.
Tu te souviens, ce fameux modèle OSI en 7 couches qui à permis l'interconnexion des réseaux.
http://en.wikipedia.org/wiki/OSI_model
En cherchant un peu tu dois bien trouver une réflexion du même genre qui critique ce modèle et qui regrette que tout le monde ne soit pas en ATM.-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 15:04. (lien). Évalué à 4.> Tu nous cites l'exemple DCOP /DBUS mais comment font ils pour communiquer avec du pur CORBA ou encore du DCOM.
Où c'est dit que cette technologie apportera miraculeusement la compatibilité universelle et permanente avec tout ce qui a existé, existe et existera ?
*relis l'article*
Ha, ça y est, je viens de piger. En fait, l'API est indépendante du protocole. Bravo, c'est la définition d'une couche d'abstraction, appliquée aux divers systèmes IPC existants.
Et ? C'est ça la révolution miraculeuse qui va tout déchirer le monde des web services ?
(d'ailleurs, j'ai du mal à voir pour quoi est fait ce truc: IPC, comme dit dans l'article, ou web service (parce que j'ai vraiment du mal à voir l'intérêt d'utiliser HTTP pour de l'IPC))
C'est une idée pas mauvaise, effectivement. Mais pas de quoi hurler à la révolution. Un truc comme ça se fait en quelques jours en python par quelqu'un qui maitrise son sujet (c'est à dire sans compter le temps d'apprentissage de DCOM/DBUS/DCOP/CORBA/...)
Mais surtout: vendre ça comme un avantage de .NET (pour revenir au sujet), c'est plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par el_mickey () le 25/06/2007 à 15:19. (lien). Évalué à -2.Quelqu'un à dit que c'était une révolution ? Bah nan. Juste que c'est une feature sexy, qu'elle est bien intégrée au framework. Et que bon ça facilité quand même grandement le développement et le déploiement.
Maintenant, si c'est si facile à faire qu'un gars le fasse en python, l'intégre au framewok et on dira : Ouah c'est une feature sexy. En attendant ...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 15:50. (lien). Évalué à 2.> Ouah c'est une feature sexy
Mais tout dépend du référentiel :) (et c'est pour ça qu'on est pas d'accord, AMHA)
Comparé à ce que j'ai ouïe dire des SOAP, CORBA, DCOM & co, effectivement, c'est beaucoup plus simple et quelqu'un qui ne connaitrait que ça pourrait sincèrement dire "c'est vraiment sympa et sexy"
Mais comparé au couple dbus/python (ou dbus/quoi que ce soit d'autre, ne soyons pas sectaires), ça n'apporte rien de concrètement intéressant, surtout pour la complexité apportée (je le répète, relativement à dbus). Et je ne trouve pas ça sexy.
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par TImaniac (page perso, ) le 25/06/2007 à 17:04. (lien). Évalué à 2.Bon alors c'est quoi ton postulat :
.NET/WCF/Web-Service c'est nul Python/DBus ca rox parcque tu peux faire tout ce que tu fais en WCF/WebServices sauf les trucs inutiles.
Alors comment fais tu aujourd'hui (avec les specs stables de Dbus 1.0) pour : (en terme de web-service)
- exposer un service à des consommateurs (au sens logiciels qui consomme les données) sur internet ?
- comment je consomme un service distant sur internet à partir de mon intranet ?
- comment je gère les transactions dans mes services sans réinventer la roue et de manière standard ?
- comment je gère le cryptage de mes services de manière standards ?
- comment j'implémente les spécifications DBus sur une nouvelle plateforme ? Je dois me coltiner un format qui n'a rien de standard ?
et maintenant pour (en terme de WCF) :
- changere le protocole de communication de mes services sans les modifier, par exemple je veux passer de web-service à com inter-process sur socket par exemple parcque mon client et moi travaillons sur la même machine pour des questions de perf.
- ajouter une couche de cryptage facilement sans toucher au code de mes services.
Les web-services répondent à une problématique bien précise : l'inter-opérabilité (au dépend des perfs souvent). Pour cela ils se basent sur des standards ouverts existant, notamment tous ceux liés au XML et ses dérivés, parcque c'est implémenté dans toutes les plateformes modernes. Au dessus de HTTP pour une raison toute conne : ca passe ces foutus routeurs. Ca résoud pas le problème fondamental, mais ca marche sur le net.
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).
Maintenant WCF pourquoi ? Parcque effectivement les web-services c'est pas toujours pertinent quand on a pas les mêmes contraintes d'interopérabilité. Alors avant fallait faire quoi ? Choisir une techno : DCOM ? Socket ? .NET Remoting ? DBus ? Web-Service ?
Et pourquoi devrais-je choisir ? Si demain je dois changer ? Si demain un client veut que je communique par web-service ?
WCF répond à cette problématique : abstraction du protocole de transport mais également abstraction de la manière d'encapsuler les données.
Je peux choisir d'exposer mes services dans différents formats sur différents protocoles simplement en changeant un fichier de conf et en utilisant les formatteurs/channelsupport livrés en standard. Voir j'en rajoute d'autre si j'ai un client chiant qui veut utiliser un truc pas standard (genre DBus).
Tu en conviendras que ca n'a pas grand chose à voir avec DBus, pas les mêmes objectifs, et qu'en l'état des specs de DBus, ce dernier ne répond pas à la moitié des problématique de Services tels qu'exposés par le WCF.
DBus c'est de l'événementiel ultra-simple. Simple parcque tout jeune. Demain ils vont vouloir exposer des services à travers internet (bon courage vu le modèle choisi qui n'est pas toujours client/Serveur) et toute les couches d'abstraction qui vont bien, ils vont vouloir ajouter de l'introspection, ils vont chercher à standardiser la façon d'échanger certains types de données, les normes de cryptage, d'authentification, de transaction, ou alors 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 plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)
Je préfère une techno qui m'expose des services et des données avec des protocoles standards et ouvert qu'un framework libre qui utilise un format proprio d'encapsulation des données.-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 18:55. (lien). Évalué à 7.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 TImaniac (page perso, ) le 25/06/2007 à 20:17. (lien). Évalué à 2.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 Moonz () le 26/06/2007 à 07:07. (lien). Évalué à 3.> 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 TImaniac (page perso, ) le 26/06/2007 à 08:25. (lien). Évalué à 2.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 (page perso, ) le 26/06/2007 à 08:31. (lien). Évalué à 2.A propos de l'ASCII, j'ajouterai que justement c'est le bordel : c'est censé être simple mais ca ne tient pas compte de l'ajout de nouveaux caractères non prévu. Du coup on a vu apparaître tous les ISO et autre UTF*. Avec toujours ce soucis de compatibilité : pas d'information autodescriptive, on ne peut reconnaître l'encodage d'un simple fichier texte, il faut utiliser des algos statistiques pour "deviner" ou demander bêtement au programmeur de donner l'info.
Ou comment une spec trop simple à engendré des outils et des problèmes d'interprétation par manque de formalisme.
(à l'époque ca se comprennait, mais maintenant c'est un boulet).
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 26/06/2007 à 09:13. (lien). Évalué à 2.Bon, je vais m'arrêter là, parce que visiblement on sera jamais d'accord et j'ai vraiment pas le temps de troller dans le vide (même si j'aimerais bien ;)). Je tiens juste à rapporter une "blague" trouvée sur un blog:
Most standards go like this:
1. Solve 80% of the problem in a matter of weeks.
2. Spend two years arguing about the last 20%.
3. Implement the 80% in a matter of weeks. Wonder why everything is so hard.
4. Spend months implementing the last 20%. Realize why the first 80% was so hard. Curse a lot.
5. Discover that the last 20% wasn’t really worth all the time spent arguing about it or implementing it.
Pour ma part, </troll>
-
-
-
-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par el_mickey () le 25/06/2007 à 20:39. (lien). Évalué à -2.>>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).
Je vois pas en quoi l'interface de WCF est si compliqué pour faire des choses simples ?
- L'interface de ton service que tu vas exposer au reste du monde.
- L'implémentation de l'interface de ton service.
- Tes types que tu décris à partir de types simples et normé comme dans dbus.
Je vois pas ce qu'il y a de compliqué. J'ai fait du dbus avec python et c# (dbusSharp) et ça se déroulait quasiment pareil et je trouve ça logique comme implémentation.
>>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...
En meme temps, c'est pas parce que les tuyaux sont libres que ce qui passe dedans l'est. Si t'as vraiment envie de faire quelques chose de proprio, tu peux aussi le faire avec dbus.
Et tu peux aussi choisir de ne pas utiliser ce protocole grace à WCF.
>>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 ?
La question que je me pose c'est: ou s'arrete cette logique de c'est quand meme pas dur à faire ? On est quand même informaticien, c'est quand même pas abherrant de vouloir se simplifier la vie et surtout de se placer des gardes fou. Histoire de pas trop se planter et de pas reinventer la roue à chaque fois.
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo le Clown () le 26/06/2007 à 12:36. (lien). Évalué à 1.Tu m'amuses
Tu attaques en disant les Web Services ca sert à rien et DBus fait déjà tout ça en mieux et plus simple.
On t'explique que les problématiques à résoudre ne sont pas les mêmes puisque pour l'un il s'agit de faire communiquer des architectures différentes et pour l'autre d'une architecture de communication particulière et que l'interêt réside dans cette différence et après tu débarques
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). comme si tu allais nous l'apprendre.
Alors effectivement sa conception ne peut être que plus simple puisqu'il ne traite l'intéropérabilté qu'avec les composants d'une même architecture. Aucun mérite donc . Heureusement qu'il n'ont pas cheché la complication. Donc tes remarques du style
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN.
sont hors sujet
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.
Non différentes architectures qu'elles soient à base de composants ou simplement RPC ou encore orientée services ou que sais-je encore peuvent commmuniquer grâce aux Web Services.
Si je veux communiquer entre du DCOM et du DBUS je devrai prévoir une passerelle particulière en se basant sur un pont) et pareil avec une impléméntation de CORBA sur un quelconque ORB ou encore du RMI ou même du simple RPC.
Je devrai attaquer des réferentiels d'objets qui n'utilisent pas les même façon d'exposer leur composant/services qui n'adoptent pas les mêmes conventions, les même structures ni protocoles d'échanges, ni les même paradigmes (procédural, SOA, architecture à base de composant)..... Bref dès qu'on souhaite communiquer en dehors de l'entreprise il faut tout remettre à plat avec chaque nouveau partenaire et redévelopper ou bien imposer à ses partenaires une migration.
Donc l'idée qui n'a rien de magique certes , c'est de se dire: Adoptons un standard de communication "inter" architecture commun. Ce standard c'est les Web Services. Tu aurais pu le comparer avec CORBA qui avait été une tentative de l'OMG de le réaliser. L'erreur qu'ils ont fait était de ne vouloir se limiter qu'a des architectures à base de composants en mode synchrone alors que si je veux m'interconnecter avec ton système d'information Je me fous de savoir quelle est ton architecture. Pour connaitre tous les comptes d'un client ca ne m'interesse pas de parcourir tous les comptes de ta banque en vérifiant qu'il appartiennent bien au client rechercher dans ta banque alors qu'un autre partenaire à décidé que ses objets clients référencaient directement leur compte ou encore que celui ci a implémenté une facade pour se faire.
Ce qui m'interesse c'est
"Quelle est la liste des RIBs du client "Duchmoll Jean Pierre" dans la banque.
J'attend qu'on renvoie un simple liste de RIB et je ne veux pas savoir comment c'est foutu dans DBUS, DCOM, CORBA ou chez toi avec ton protocole personnalisé au dessus de RPC.
Moi je comprend mais surtout mes AMOs comprenent et là ils se disent que cette requête peut servir dans des autres procesus métiers ou que ce processus peut être amélirié si je la place à un autre endoit . Il peuvent faire des simulation et moi en tant qu'architecte je peux enfin capitaliser sur un catalogue de services réutilsable sans m'arracher les cheveux à chaque evolution du besoin.
Et là on rentre dans le SOA.
http://en.wikipedia.org/wiki/Service-oriented_architecture
Et là on commence à comprendre l'intérêt de WCF puisqu'il unifie tout dans une approche orientée service que ce soit dans mon réseau d'entreprise ou sur internet.
Voilà lorsque tu auras déjà admis ca et la compléxité inhéhente qui en découle (y'a pas d'appproche saine ou pas saine à avoir) tu pourras te pencher sur l'implémentation et comprendre l'interêt de celle de M$ et comparer sa compléxité avec des autres approches du même type. Pas en comparant avec l'API de DBUS comme tu le fais.
Quand ca t'arrange la comparaison vaut le coup et quand ca ne t'arrange pas il faut pas mélanger les torchons et les serviettes.
-
-
-
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Thomas Douillard () le 25/06/2007 à 14:44. (lien). Évalué à 2.Ça m'a l'air pas très complexe et très souple comme solution ça. Il répondrait quoi à "gagner beaucoup de souplesse contre un peu de complexité" ton bonhomme ? Sans compter que là, on gagne en cohérence, ce qui simplifie plutôt le problème si tu veux mon avis, et ça masque l'implémentation du truc, on gagne en généricité. On a juste à connaître l'interface du service pour l'utiliser.
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 15:29. (lien). Évalué à 3.Il répond très simplement: comparé à dbus, c'est pas beaucoup plus souple (oui, théoriquement, tu es indépendant du protocole. Mais en python aussi avec dbus, puisque c'est exactement la même chose: on fait tout avec des décorateurs et on ne définit qu'une api, pas un protocole !) et BEAUCOUP plus compliqué (avec dbus, c'est JUSTE des décorateurs. Pas de fichier de configuration, pas de fichier source autogénéré, pas de fichier interface autogénéré, rien. Juste quelques décorateurs).
Après, faut voir avec quoi tu compares. Si tu compares avec les anciennes technologies proprios de ce type, je n'en sais rien, je connais pas. Si tu compares à DBUS, ça n'apporte vraiment rien.
-
-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par el_mickey () le 25/06/2007 à 14:56. (lien). Évalué à -2.Bah peut être tout simplement, programmer ton interface. Et aprés juste dans un fichier de configuration dire : tiens c'est utilisable par web service ou tiens dbus peut y accéder aussi (bon même si en l'état actuel y'a pas même si ce serait envisageable je pense).
Et bon niveau complexité c'est 4 lignes de code pour exposer ton interface et 5 lignes de configuration...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 15:39. (lien). Évalué à 4.Je veux pas faire ma mauvaise langue, mais ça me fait fortement penser au système de GNOME qu'ils sont tout doucement en train d'abandonner au profit de quelque chose de plus simple comme dbus...
Ce qui me dérange, c'est qu'on commence à faire une énorme couche d'abstraction bien lourde juste pour le plaisir, sans qu'il y ait de réel besoin pour ça
Alors qu'une couche mince et simple aurait fait l'affaire
C'est à dire l'opposé complet des conseils de bonne programmation unix
Mais c'est dans la continuité des .NET, C#, Java & co après tout :)
-
-
-
-
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Plop () le 25/06/2007 à 13:17. (lien). Évalué à 5.1) Faire tourner une application avec le minimum de privilège possible est la base de la sécurité. Tout les bons démons unix laissent tomber leur privilège root pour s'exposer le moins possible aux attaques.
Tu es du genre à te connecter en root ?
Ca n'a rien à voir avec ta collection de mp3 que les méchantes "majors" veulent t'empêcher d'écouter. (si j'ai bien compris le sens de ta petite phrase)
2) Je préfère utiliser des webs services utilisant SOAP que COM/DCOM ou ActiveX.
3) non, ce n'est pas une farce.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 13:32. (lien). Évalué à 5.> 1) Faire tourner une application avec le minimum de privilège possible est la base de la sécurité
Je suis d'accord :)
> Tout les bons démons unix laissent tomber leur privilège root pour s'exposer le moins possible aux attaques.
Oui, mais ils demandent ça à l'OS. Ce que je veux dire par "c'est ridicule de présenter ça comme un avantage", c'est que ce n'est pas le boulot du langage ou de la VM, mais de l'OS de contrôler si les applications ne font pas plus qu'elles ne sont autorisées...
C'est un peu comme si tu faisais un protocole applicatif qui s'occuperait du routage des paquets. C'est totalement ridicule...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo le Clown () le 25/06/2007 à 14:00. (lien). Évalué à 4.Et comment l'OS vérifie qu'un applet que je je télécharge accède à des fichiers auxquel je ne souhaite pas l'autoriser ou qui seraient sensibles. En l'empêchant d'accéder à tous les fichiers parce qu'il n'a pas les droits root ou en créant des ACL dédiés à l'utilisateur qu'il devra appliquer sur tous les fichiers sensibles. Ca va être portable ça
http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 14:14. (lien). Évalué à 3.De la même manière que les démons Unix baissent volontairement leurs privilèges, le programme demande à l'OS d'appliquer une politique de sécurité plus stricte pour le process représentant l'applet avant de la lancer
> Ca va être portable ça
Ça pourrait faire l'objet d'une couche d'abstraction dans l'API de base de .NET, là ça ne pose aucun problème. Si t'es sous Linux -> SElinux, si t'es sous Vista -> je sais pas quoi, etc...
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Plop () le 25/06/2007 à 14:42. (lien). Évalué à 2.L'OS n'a pas toujours la granularité nécessaire. Ce n'est pas l'OS qui va dicter si l'utilisateur TOTO de ton appli web a le droit d'accéder au formulaire administratif. c'est l'application qui prend en charge ces fonctionnalités.
Exemple : ce n'est pas à l'OS de vérifier si le Certificat client SSL est valide pour savoir si on peut laisser l'utilisateur utiliser http://linuxfr.org ou https://linuxfr.org.
Autre exemple, le systeme de gestion de paquet de Debian gère les signatures des paquets avant d'installer un paquet. C'est la même chose pour la signature des DLL .Net. La VM vérifie que le signataire de la DLL ou l'exe est une personne de confiance avant d'autoriser l'accès à tel ou tel partie du framework.
je te conseille la lecture de http://www.c-sharpcorner.com/UploadFile/Razi%20Bin%20Rais/Do(...)
pour mieux comprendre les concepts.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz () le 25/06/2007 à 15:18. (lien). Évalué à 3.> Ce n'est pas l'OS qui va dicter si l'utilisateur TOTO de ton appli web a le droit d'accéder au formulaire administratif.
Effectivement, parce que le formulaire administratif n'est pas une ressource que l'OS gère
Mais moi, je répondais à:
>> accède à des fichiers auxquel je ne souhaite pas l'autoriser ou qui seraient sensibles.
Et les fichiers, c'est une ressource que l'OS gère. C'est même son boulot, et si tu n'es pas d'accord avec ça, va voir du côté des exo-noyaux. Pour le données d'une base de donnée, c'est effectivement le rôle de la base de donnée de gérer les autorisations. Mais l'OS a la responsabilité que personne ne puisse accéder au fichier de la base de donnée (à part la BDD elle même évidemment)
Note que je ne suis pas contre une belle API qui centralise tout ça. Mais une telle API DOIT se baser sur les services fournis par l'OS (ACL, SElinux, chroot, sudo,...). Ce ne doit pas être un bête wrapper autour de open...
> Autre exemple, le systeme de gestion de paquet de Debian gère les signatures des paquets avant d'installer un paquet.
J'ai dit: c'est le rôle de l'OS. Je n'ai pas dit: c'est le rôle du noyau
Le système de gestion de paquets fait partie de l'OS Debian GNU/Linux, et c'est effectivement son rôle de vérifier que n'importe qui ne puisse pas corrompre les programmes ou les bibliothèques partagées installés... C'est pour cela que Java WebStart est une aberration sur une distrib Linux !
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
-
-
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par ragoutoutou () le 25/06/2007 à 14:05. (lien). Évalué à 3.+ La séparation des privilèges d'unappli .Net est très intéressante. Ainsi, on peut exécuter une appli en l'empêchant d'accéder aux ressources locals (disque dur, réseau...) Il est possible ainsi de sécuriser un code avec une granulométrie qui est celle d'une méthode
Si c'est le framework qui fait sa popote au niveau privilèges, ça augmente tout de même les risques par rapport à une application dont la mise en place a été faite avec une réduction consciente des privilèges par les admins, voir avec utilisation de technologies comme SELinux...
Faire tourner une appli .Net comme root en comptant sur le framework pour filtrer les opérations n'est pas une approche saine en tout cas...
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par briaeros007 () le 26/06/2007 à 09:34. (lien). Évalué à 5.euh pour un point :
Si tu dois interdire a un code d'acceder a une ressource ... c'est pas au niveau ni du langage, ni de la vm, mais au niveau du système!
Pour la signature cryptologique , oui c'est interessant... mais si tu t'amuse alancer n'importe quel appli qui vient de n'importe ou c'est que tu as un probleme.
La signature d'un module vient d'un besoin précis. En contrepartie l'utiliser a tort et a travers (je ne sais pas comment ils l'utilisent) on peut voir une possibilité de tivoisation de certains code (style vérifier que le code provenant de cette clé publique marche... Et comme tu as pas la clé publique, seul les modules du constructeur/... peuvent etre utilisé.)
Pour le binaire j'avoue ne pas comprendre.
Tu veux dire que du c++ et du java peuvent etre utilisé dans le meme programme? Oui... mais tu dois passer par la vm donc l'intéret est somme toute limité. Puis je croyais que le framework était complet, donc tu devrais pas avoir besoin de réutiliser du vieux code c++ ...
Quant au framework 'complet et homogène'. Je sais pas je le trouve pas si complet que ca mais bon c'est que je dois etre grognon.
D'autres points : a été pensé comme concurrent de java, plutot que d'essayer d'apporter des briques a java. Maintenant que la vm sun est libre, tu vas ausis pouvoir foutre une 'compatibilité binaire entre java et c++' ... - oui c'est intrinsèque ... a la vm, pas à .net, vu que c'est la vm qui convertis le byte code en binaire ---
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Taku (page perso, ) le 25/06/2007 à 12:28. (lien). Évalué à -1.Et du point de vue de la techno SilverLight, ca a l'air vraiment violent.
Je n'ai pas encore trop compris sinon comment ca se présentait dans son déploiement et dans le développement d'applications, mais sincèrement faire du Flash-like vraiment technologique, plus intégrable que java, et moins "cuisiné" que Flash, ca me tente vraiment beaucoup ... et pourtant des a priori sur cette techno, j'en ai eu quand j'en ai entendu parler la première fois. Mais la ...-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Bozo le Clown () le 25/06/2007 à 12:45. (lien). Évalué à 3.Attend de voir le dernière née des techno java qui passe en
opensource
http://www.sun.com/software/javafx/index.jsp
https://openjfx.dev.java.net/
Sans oublier Flex3 qui sera sous GPL aux dernières nouvelles et qui te permet de ne plus faire joujou directement avec le Flash
http://labs.adobe.com/technologies/flex/-
[+] [^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Taku (page perso, ) le 25/06/2007 à 13:18. (lien). Évalué à -1.Autant pour Java ... mais Flash non. Ce n'est définitivement pas (à mon avis) un truc à mettre entre les mains d'un développeur.
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
-
-
-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par reno () le 25/06/2007 à 14:57. (lien). Évalué à 4.>du Flash-like vraiment technologique, plus intégrable que java, et moins "cuisiné" que Flash,
Gneh? Tu n'es pas clair..
Ca veut dire quoi 'vraiment technologique'?
'Plus intégrable que java' bah évidemment, Microsoft integre .Net dans Vista, alors forcément avec 95% du marché, avec le renouvellement du parc, a (long) terme ce sera intégré..
'cuisiné'?
Je ne comprends rien a tes termes..-
[^]Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Taku (page perso, ) le 25/06/2007 à 20:48. (lien). Évalué à 1.Totalement d'accord avec toi, je l'ai un peu écrit à l'arrache ce message, j'en suis désolé ...
Non je voulais dire que cela semblait être plus intégrable à une page web, quand on voit par exemple la vitesse à laquelle charge la page que présente Icaza.
Ensuite le "vraiment technologique" était vraiment mal dit, désolé encore, je voulais dire que ça apparaissait vraiment comme une techno de très haut niveau, permettant de faire des choses que java ne permettrait pas de faire aussi simplement.
Ensuite quand je parle de "cuisiné" si je précise que je fais référence à actionscript, je pense que c'est largement compréhensible :)
Bref pour résumer je voulais juste dire que ça m'apparaissait vraiment intéressant.
-
-
Grmbl..
Peut-on avoir la vidéo de l'interview sur un autre support ?
Ca fait 5 fois que j'essaye de voir le truc sans succès.
On a long enough timeline, the survival rate for everyone drops to zero.
-
[^]Re: Grmbl..
Posté par David () le 25/06/2007 à 12:58. (lien). Évalué à 2.C'est du "Macromedia Flash data (compressed), version 7" non supporte par mplayer.
Bon le flv, ca peut encore passe (avec "clive") mais la, Hop, a la trappe la video.-
[^]Re: Grmbl..
Posté par dawar (page perso, ) le 25/06/2007 à 13:01. (lien). Évalué à 2.http://www.brainsonic.com/webtv/tv4it/contents//2007/2007062(...)
En plus la définition est bien plus importante, la video dans le flash est deux fois plus petite...-
[^]Re: Grmbl..
Posté par dawar (page perso, ) le 25/06/2007 à 13:02. (lien). Évalué à 2.Ha oui, et ça passe nickel dans le dernier VLC.
-
-
-
[^]Re: Grmbl..
Posté par knarf2 () le 25/06/2007 à 13:38. (lien). Évalué à 3.J'espère que Silverlight permettra de diffuser des vidéos correctement.
Avouez, le fait de diffuser l'interview sur "TV 4 it" tout laid, c'était une technique de sioux pour nous convaincre que Silverlight© c'est mieux §!--
On a long enough timeline, the survival rate for everyone drops to zero.-
[^]Re: Grmbl..
Posté par Raphaël Gertz (page perso, ) le 25/06/2007 à 14:14. (lien). Évalué à 3.Je sais pas ce qu'est cette chaîne, mais j'ai un seul constat, ici ça marche pas !
Malgré le plugin flash proprio tout pourrit en version 9, j'ai juste leur appliquette qui monte a 100% de cpu système utilisé et reste bloqué a 0% de chargement.
Je passerais sur les NOMBREUSES erreurs javascript de leur site web au passage.
Nan sérieusement quelqu'un a le .flv lisible sans ces merdes ?
ps : je suis pas fondamentalement contre flash, mais quand avec une mandriva 2007.1 a jour + plugin proprio ça marche pas je deviens intégriste...-
[^]Re: Grmbl..
Posté par Raphaël Gertz (page perso, ) le 25/06/2007 à 14:35. (lien). Évalué à 3.Bon, comme dirais l'aure, aide toi, toi-même....
La vidéo en flv (27Mo) :
http://rapsys.free.fr/video/mono-silverlight-micaza.flv
Konqueror + plugin proprio : 100% d'usage (inutilisable)
Firefox + plugin proprio : 80% d'usage du cpu (lag)
Mplayer (sans changer d'option ni rien) : 0%
Bon a comparer a youtube/dailymotion qui eux ont un usage dépendant des dimensions de la fenêtre vidéo.-
[^]Re: Grmbl..
Posté par Bozo le Clown () le 25/06/2007 à 14:41. (lien). Évalué à 2.
Mplayer (sans changer d'option ni rien) : 0%
Tu veux dire que t'as droit à un core dump :)-
[^]Re: Grmbl..
Posté par Raphaël Gertz (page perso, ) le 25/06/2007 à 15:12. (lien). Évalué à 2.Non, je parle de ce que montre kcpuload...
J'ai une athlon 3200+ 512k, en général le moniteur de charge reste tout noir avec des points vert.
Le pire des cas est quand je lance un jeu sous wine, là il monte en consomation cpu (normal), attente active, tout ça...
Alors quand je vois que mplayer me lis une vidéo sans barre verte.
Et de l'autre côté une appliquette flash arrive même pas a le faire alors qu'elle supporte moins de format de vidéo, ça me fait bondir.
-
-
-
-
[+] Silverlight
Merci pour la vidéo.
Si cette technologie peut remplacer Flash pourquoi pas ! Ca donne envie de s'y essayer en tout cas.
-
[^]Re: Silverlight
Posté par Farvardin (page perso, ) le 25/06/2007 à 16:30. (lien). Évalué à 10.je dirais plutôt : si cette technologie peut encourager Adobe à libérer Flash, pourquoi pas !
En tout cas même si Adobe sortait un "flash composer" payant pour Linux (avec un lecteur flash opensource, et des spécifications complètement ouvertes permettant aux programmeurs de développer des composeurs opensource), je trouverais cela toujours plus intéressant que ce silverlight en partie "libre", en partie dépendant de mono, en partie "ptet qu'on va bien vous nik** avec tout ça", en partie "ptet qu'on va seulement autoriser les distributions linux qui ont payé la dîme et qui ont signé le pacte à utiliser tout ceci..."
Et de toute façon cela sera toujours avec un train de retard par rapport aux spec de microsoft, et cela causera bien du soucis à ceux qui ont choisi linux si cette horreur se développe plus...
Bref, ça sent vraiment très très mauvais tout ça.--
Tous ensemble contre l'esclavitude des logiciels privateurs !-
[^]Re: Silverlight
Posté par hervé Couvelard (Jabber id, page perso, ) le 25/06/2007 à 17:39. (lien). Évalué à 2.@Bref, ça sent vraiment très très mauvais tout ça.
Comme tout ce qui vient de microsoft.-
[^]Re: Silverlight
Posté par Bruno Ethvignot (page perso, ) le 25/06/2007 à 18:17. (lien). Évalué à 1.Mike Shaver, directeur canadien de l'écosystème de développement de Mozilla, dubitatif la technologie client riche propriétaire de Microsoft connue sous le nom de « Silverlight » :
« Silverlight a pour objectif de faire passer les développeurs d'une technologie ouverte, qui leur laisse beaucoup de pouvoir, à une technologie contrôlée par un seul acteur, Microsoft ». Le danger étant de les laisser se positionner en « source unique de technologie » et de passer d'un « ensemble d'outils simples à une seule grosse plateforme, isolée ». Il s'avoue tout de même « soucieux » que Microsoft « soit réellement en mesure de les attirer vers sa plateforme », en leur offrant « de bons outils de développement » et en y consacrant d'importants moyens financiers.
Vu sur Vnunet.fr : « Mozilla : Mike Shaver dubitatif sur Silverlight et IE7 »
http://www.vnunet.fr/fr/vnunet/news/2007/06/22/mozilla-mike-(...)-
[^]Re: Silverlight
Posté par Plop () le 25/06/2007 à 20:20. (lien). Évalué à 6.ben quand Mozilla aura compris que pour démocratiser XUL (mozilla product only d'ailleurs), il faut des environnements de dev sexy.
Oui, MS va tout faire pour faire adopter sa technologie. et fournir des outils de dev modernes c'est la clef.
Mozilla avait avec XUL un train d'avance qu'ils viennent de perdre parce qu'ils n'ont pas su "vendre" cette techno. Ils pensaient surement que leur techno était suffisament attractive
Pourtant, je pensais - qu'avec le tapage marketting qu'ils font avec Firefox - qu'ils étaient plus aguerri dans ce genre d'excercice.
C'est très dommage AMHA. Le train est passé, ils n'ont plus qu'à courir.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: Silverlight
Posté par Taku (page perso, ) le 25/06/2007 à 20:54. (lien). Évalué à 5.Tout à fait d'accord.
Une technologie libre c'est bien.
Une technologie performante et sexy, c'est mieux.
(à un instant t bien entendu, la libre pourra ensuite s'inspirer de l'autre, et s'améliorer, et blablabla ... )
Il est vrai qu'OpenOffice a gagné des parts de marché dans un premier temps pour son prix (ou son absence de prix) mais firefox c'est uniquement parce qu'il est vraiment plus performant et attractif (tabs, CSS, RSS), et pas parce qu'il est libre (en tout cas pas chez 90% de ses utilisateurs).
-
-
-
-
Cette page a été générée par Templeet en 0.228s (dont 0.0322 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.