TImaniac a écrit 6420 commentaires

Ou ça ?
Ben y'a pas de liste exhanstive des formats d'image à supporter : comment veux tu implémenter ce format sans savoir quoi supporter comme codec d'image ?
Y'a pas de liste exhaustive des langages de scripts possible, et encore moins de référence à une quelconque norme/version : que dois-je implémenter pour avoir un document qui exécute correctement les scripts ?
Pareil pour les applets Java : on sait pas quelle version de Java est référencée, laquelle implémenter, avec quelles libs (on suppose que JDBC en fait parti, sans savoir quelle version).

Peu m'importe que MS fasse un format de stockage OOXMLBis non normalisé qui inclut des images en RAW
Justement, selon la norme actuelle, tu peux très bien mettre une image RAW, la norme ODF est parfaitement respectée. Mais tu peux pas relire ton document si OOo (ou autre) ne supporte pas ce format d'image. C'est couillon non ?

Ca te suffit pas à prouver qu'il est impossible d'implémenter ODF correctement ?

C'est pas pour ca qu'il faut jeter ODF, juste qu'il faut accepter qu'une norme est pas parfaite, et chercher à l'améliorer. mais faut pas la rejeter, rien n'est parfait.

Il le devra SEULEMENT si ms FORCE son format (abus de position dominante).
Bah voyons. Si OOXML est utilisé, c'est uniquement parcque MS va abuser de sa position dominante. Il est où l'argument là ?

Je rappelle que le format ACTUEL d'office n'EST PAS OOXML. Il y en a une partie, mais il n'est pas complètement conforme à la norme.
Forcement, la norme existe toujours pas, elle risque encore de bouger. Mais tu peux quand même conserver 90% de la doc, et ca aide vachement les développeurs, quoique t'en dise.

C'est pas franchement l'avis des personnes qui ont étudié la norme, mais c'est pas grave hein.
Y'a 3 types de personnes qui ont étudiés la normes :
- IBM & Co : ils sont partisan, et n'y ont cherché que des bugs.
- les bloggers et autres amateurs (comme moi) : ils s'improvisent spécialistes, ca vaut pas grand chose.
- Les développeurs, ceux à qui s'adresse la doc, qui s'y connaissent en suites bureautique. MDI en fait parti. D'autres développeur (j'ai cité un de Gnumeric plus haut). Et eux sont content, ils la trouvent pertinente cette doc, même si elle est loin d'être parfaite, c'est un putain de pas en avant.

Après tu prends l'avis de qui tu veux, mais pour moi l'avis des derniers me paraît beaucoup plus pertinent.

Et quid de la clause de liberté de redistribution ?
Bah c'est du logiciel "libre", tu peux redistribuer sans problème Moonlight. Novell t'offre pas de protection c'est tout (ce qui est normal, tu n'offres pas de garantie sur un truc potentiellement modifié). Pas plus que quand tu télécharges la grande majorités des softs libres sur ton repository favori : t'as pas de garantie. (A moins de payer un service à RedHat ou Novell par exemple, qui t'offrent différents niveaux de garantie, logicielle, juridique, etc.).
C'est marrant ca : Novell essai de couvrir ses utilisateurs contre un système de merde, c'est pire que de ne rien faire ?

Ce qu'on nomme traditionellement 'FUD'.
Voilà, t'as tout compris le système de brevets : c'est un FUD permanent. Ce qu'il t'explique, c'est que ce FUD ne s'applique pas uniquement à Moonlight, mais à l'ensemble des logiciels (libres ou pas d'ailleur). Le vrai FUD c'est oublier de mentionner que le risque des brevets n'est pas cantonner à Moonlight.

1°) As tu une preuve qu'il y a des brevets sur linux ou OOo? Si oui tu serais aimable de donner des liens vers les brevets. Je te jure qu'on va recoder pour ne plus avoir ce genre de probleme.
Le problème, c'est qu'avec les brevets, par définition on est sûr de rien : déjà des brevets potentiellement impliqués, des softs potentiellement impliqués, et du véritable risque juridique. Ce qui est sûr, c'est que les grosses boîtes comme Novell, RedHat et autres Philips ont monté un consortium pour protéger certains produits "à risque", et bizzarement le kernel et OOo sont explicitement cité comme étant cibles "à protéger".
Enfin si tu veux un exemple pour ODF, c'est facile : ODF nécessite Java (applet, JDBC) qui nécessite MPEG-4. C'est de renommée notoire que MPEG-4 est couvert de brevets.

4°) et pourquoi mono ne serait pas attaquer en premier?
Rien ne peu le dire. Mais un peu d'étude stratégique permet de faire des suppositions à peu prêt intelligentes : Mono va dans le sens de l'expension de .NET, il contribue à étendre la techno. MS supporte officiellement Mono à travers ce partenariat avec Novell autour de Moonlight (ca vous paraît anodin, mais c'est une reconnaissance explicite de la légitimité du produit). OOo ne participe pas vraiment à l'expansion des technos MS : c'est un concurrent. Ne parlons pas de Samba, qui ouvre un protocole dont MS tirait de gros avantages à le garder fermer (Il faut une machine Windows pour accéder à ce genre de partage).
Après personnellement je vois pas MS attaquer ni Samba ni OOo, parcqu'ils se décrédibiliserait et ces softs sont protégés par le consortium dont j'ai parlé, qui regroupent des boîtes qui ont les moyens de se défendre.
Mais Mono ou Moonlight n'est pas plus dangereux que le reste c'est tout.

Ce qui est rigolo, c'est que tout le monde s'accorde à dire que MS passe son temps à FUDer sur l'insécurité des logiciels libres, et vous reprenez exactement leur FUD pour tenter de décrédibiliser... un logiciel libre, tout ca parcque vous aimez pas le produit.

Tu peux tres bien attaquer un soft ou tu as 97% de chance de gagner
Sauf qu'ils n'ont aucune chance de gagner, rappelons que Novell détient des brevets... sur .NET, et mono est couvert par le dis consortium. Dans ce genre de procès, il n'y a de toute façon pas de gagnant ou de perdant officielle, juste des tractations financières au bout sous la table, et un rejet de la plainte. (système US inside).

Bref, dire que Moonlight est dangereux en supposant une éventuelle attaque de MS, c'est la définition même du FUD. C'est pas faux, mais c'est absurde de le prendre comme argument pour pousser à utiliser d'autres technos qui sont exactement dans la même solution.

Discussion entre revendeurs d'armes :
- Achetez pas ses armes, elles tues !
- Oué un peu comme les tiennes.

Donc toutes tes critiques sur ODF sont nulles et non avenus.
Mais c'est quoi cette conclusion de merde ? Je suis pas représentant MS que je sache ! Je donne mon avis.

Microsoft ne l'a pas fait tout simplement parceque bien sur qu'il y a des manques, des erreurs et des trucs qui ne devraient pas etre dans ODF 1.0 mais ce format est totalement implementable dans n'importe quel suite office.
J'ai montré par A + B qu'il n'était pas implémentable entièrement dans la vraie vie. La vraie vie me donne raison, puisque personne n'a encore réussi et ca maintenant un petit moment que le standard existe.
MS a voté Oui par pragmatisme : ce format n'est pas 100% interopérable, c'est un saint graal de toute façon inaccessible, proposons un autre format qui n'atteindra pas non plus l'objectif mais qui répondra à un autre : la compatibilité avec des millions de documents existants.

Pourquoi avoir voulu absolument repeter les erreurs de ODF et du format binaire?
Parcqu'il y a des contraintes techniques ? Les objets OLE, c'est du bon gros blob binaire, mais des gens s'en serve, et il faut que ces gens puissent sauvegarder leurs documents quand même dans un format moderne : tant pis si certains bouts seront potentiellement illisible plus tard. C'est pour ca que ODF et OOXML supporte OLE.

. Maintenant microsoft a 6 mois pour montrer sa veritable volonte d'avoir un format de fichier office reellement interoperable et perenne avec les autres acteurs du marche, donc wait and see.
ODF est pourtant passé depuis en 1.1 à l'ISO (l'année dernière, donc relativement recemment), et pourtant il n'a pas beaucoup été amélioré niveau interopérabilité : impossible d'être 100% compatible avec 90% des suites déployés sur le marché, balo pour un format d'interopérabilité non ? Sauf si on est pragmatique, et qu'on accepte ces entorses pour avoir quand mêmes des formats normalisés, et on accepte l'OOXML comme on accepte l'ODF.
Un peu de cohérence bon sang, les 2 ou aucun.

Ca te rappelle rien ca? Pourquoi ne pas avoir pris la decision d'utiliser le standard qui etait en train de se mettre en place pour corriger exactement le meme manque dans ODF, je parle d'openformula?
Pourquoi prendre OpenFormula, un truc neuf, pas encore normalisé à l'époque, et qui est rien d'autre qu'une copie à peine modifiée du format d'OOo ? MS a son propre format, déjà éprouvé. Pourquoi prendre le truc concurrent qui n'a pas plus de légitimité ?

Enfin je vois que t'as pas répondu sur la moitié de mes exemples.

Quelle est la différence de but ?
Y'a des buts communs :
- proposer le logo commercial "ISO"
- proposer un format avec une certaine pérénité dans le temps (suppose des choix techniques type XML et une documentation relativement complète).
Des buts différents :
- ODF veut proposer un standard qui repose sur OOo. En cela historiquement le format proposé est plus "clean" et s'affranchi plus du passé.
- OOXML veut proposer un standard qui repose sur MS Office. Moins clean, il offre cependant l'avantage d'être compatible avec l'énorme historique de documents existant.

Bref OOXML est un bon format de transition pour une administration qui vient du monde MS Office.

ODF est un bon format pour qui veut passer à autre chose.

Pourquoi pas implémentable ? Surtout que maintenant MS office sait produire du xml, y'a déjà une partie du boulot qui est fait. J'ai pas l'impression d'une quelconque difficulté technique.
Lis mes différents exemples sur les grosses lacunes de la norme ODF et les liaisons (trop) fortes avec les technos de Sun.
Lis également les difficultés rencontrées par ceux qui tentent d'implémenter ODF (KOffice, Gnome Office). C'est parfois surmontable, mais au prix d'hypothèse techniques qui consiste à "singer" OOo pour être compatible. Je vois mal MS "singer" OOo juste pour être compatible avec lui.

? Peut etre que le fait que C# 2.0 et C# 3.0 ne sont pas ISO, casse la compatibilite avec la norme ISO.
Mouarf ! L'excuse bidon. Déjà on parle pas du langage, mais d'un bytecode d'applet, on parle donc de la CLR vs Java. Donc C# 2.0 ou C# 3.0, s'est pareil, c'est la CLR 2.0. Cette dernière est en cours de normalisation ISO. Et je vois pas ce qui empêche de supporter la CLR 1.0 dans la version actuelle d'ODF et de passer à la CLR 2.0 lors du prochain draft ODF.
De toute façon c'était juste un exemple pour montrer 2 choses :
- ODF utilise aussi des trucs non ISO, même quand y'a des trucs à l'ISO : d'après vos théories à 2 balles, ODF "réinvente la roue" et ne devrait pas être ISO.
- La présence de Java et autres JDBC qui non rien d'ISO ou même OASIS/ECMA/cquetuveux montre clairement l'influence omniprésente de Sun sur l'ODF, et relativise complètement vos arguments bidon concernant l'ouverture du processus de standardisation à l'OASIS et l'indépendance vis-à-vis d'une entreprise. Dans la vraie vie, ODF est aussi liée à Sun que l'est OOXML à MS.

Enfin bon tu me montres les manques dans la doc de Java STP.
Mais on sait même pas de quoi on parle ! C'est juste marqué "applet Java", ca inclu quoi ? Quelle version de la plateforme ? Quelles bibliothèques ? On sait même pas quelle doc lire !

De meme pour javascript, la doc est la ou pas?
Quelle version ? L'ECMAScript (là encore ils parlent de Javascript, ca en dit long sur l'indépendance envers Sun) a plein de version, la dernière étant peu implémentée, je prend laquelle ? ECMAScript 4 qui apparaîtra dans le futur Mozilla ? Un plus vieux ? Lequel ?
De plus c'est clairement mis "for example", je peux très bien y mettre du Python ou du Ruby, voir du Perl ou n'importe quoi, non seulement certains de ces langages sont notoirement mal spécifiés (Python) et il est impossible de supporter universellement tout et n'importe quoi !

Ah non non il est pas passe comme une lettre a la poste, il est carrement passe a l'unanimite et pas en fast-track.
Oui excuse moi, même à la poste ils ne sont pas aussi efficace. T'as saisie l'idée : certaines énormités n'auraient jamais dû passé. Ou alors si ca n'a dérangé personne à l'époque, faut pas venir faire chier l'OOXML avec des critiques du genre.

Si Microsoft avait des commentaires a faire sur le format ODF ils avaient qu'a le faire avant de voter.
MS ne remet pas en cause la normalisation à l'ISO d'ODF je te rappelle.

Si toutes les corrections demandes sont mises en place pour fevrier, je ne vois pas pourquoi le format ne passerait pas la norme ISO.Sauf que grosso-merdo, les détracteurs d'OOXML comme IBM & Co ne veulent pas de corrections, ils cherchent juste un maximum d'arguments pour que le format ne soit pas normalisé du tout, en tout cas le plus tard possible, pour que seul ODF est le logo ISO.

Le seul probleme c'est que je vois assez mal Microsoft faire evoluer son format de facon a respecter cela car il faudrait mettre a jour tous les Microsoft Office 12 vendu.

Je ne vois pas où est le caractère obligatoire. Après MS sort toujours des services packs, des plugins d'import/export, des patchs, et des versions majeurs. Y'a que l'embarras du choix pour diffuser ce support.

Cela me ferait bien chier d'avoir 2 formats totalement redondant
C'est pour ca que j'ai tenté d'expliqué que ces formats ne sont pas totalement redondant, même si une grande partie se recoupe, ils n'ont pas le même objectif, ce qui se voit facilement aux différents arguments des détracteurs de tout bord : les avantages de l'un sont des inconvénients pour l'autre.

attendant la proposition de norme tel que presente n'etait pas en etat pour etre une norme ISO.
Je suis bien d'accord, même mine de rien quand on y réfléchi, l'ODF était pas plus prêt. La V1.1 comble la plus grosse énormité, mais y'a encore du boulot.

Mais sérieusement ca te choque pas tout ce que j'ai trouvé sans être expert et que ca soit passé à l'ISO ???

Tu veux pas essayer d'argumenter plutôt que de poser des affirmations gratuites et chercher à dénigrer les propos de l'autre en tentant de l'humour à 2 balles ?

Implémenter entièrement ODF suppose d'implémenter Java par exemple plutôt que de réutiliser les normes ISO qui existent (bah oué CLR/C# c'est ISO) : ca te choque pas ?

Gueuler après l'OOXML qui propose l'inclusion de blob binaire, notamment les composants OLE, quand l'ODF propose également d'inclure des composants OLE, ca te choque pas que la critique n'aille que dans un sens ?

ODF oublie de préciser les formats d'images qui doivent être supportés, on peut en déduire d'après les exemples de la norme ODF qu'il doit être possible d'inclure les formats JPG et GIF (alors que pour ce dernier y'a PNG qui est norme ISO) : où s'arrête-t-on dans le support des formats ? Un format d'image qui n'est pas utilisé par OOo mais par une autre suite est considéré comme un blob binaire ? Pourtant ca respecte bien la norme qui "oublie" de proposer une liste finie de formats à utiliser. Ca te choque pas ?

L'ODF propose d'inclure des scripts qui peuvent là encore être "par exemple" en Javascript... ca suppose encore implémenter ce langage si on veut supporter intégralement un document pondu par OOo ? Et si j'utilise un autre format de script, à priori l'ODF ne m'en empêche pas, comme pour les images non ? Ca te choque pas d'un point de vue interopérabilité ?

Ca te choque pas que tout ca soit passer comme une lettre à la poste à l'ISO ? Tu trouves que c'est des "détails" ? Tu trouves normal que l'ISO est accepté sans bronché qu'un format de feuille de calcul ne propose pas dans la V1 de documentation sur comment écrire... les formules? (corrigé avec OpenFormula dans la V1.1) ?

Dernier point : ca te choque pas que j'ai trouvé la plupart de ces "énormités" en lisant en diagonale les specs d'ODF ? Que vais-je trouver si je lis toute la norme ?

Si rien de tout ca ne te choque (ce qui ne m'étonnerait pas vu comment ton objectivité et ta haine viscérale de MS t'ouvre l'esprit), je vois même pas ce que trouves à redire sur l'OOXML, il est au moins aussi "magnifique" qu'ODF.

Tiens tant que j'y suis, je continuais à lire en diagonal la norme ODF pour voir toutes les énormités qui s'y trouve, je suis tombé sur les formats d'images :
D'après les exemples proposés, on peut inclure des images .gif. Pourquoi gif ? Pourquoi ne pas faire référence explicitement à la norme ISO du format PNG largement implémenté et bien plus performant ?
Plus loin je vois une référence à un JPG... mais où est la liste exhaustive de tous les formats d'images à implémenter ? Je peux utiliser n'importe quoi ? Non je suppose que là encore, la référence c'est OOo, c'est comme pour OpenFormula : z'avez qu'à regarder ce que fait le soft de référence.
Attention, là encore je ne dis pas que OOXML est mieux sur ce point, mais je cherche à attirer l'attention sur le fait que l'ISO normalise des trucs qui théoriquement ne devrait pas l'être, comme l'ODF, et des trucs gros comme ca que je trouve en 5 minutes. Pas des détails qui plus est. Donc faire chier l'OOXML pour son manque de documentation (et quand on voit les chipotages des critiques techniques, on se pose des questions), je trouve ca vraiment pitoyable, pour MS et SUN encore je comprend, y'a une raison commercial, pour le libre, c'est de l'anti-MS primaire.

* ne pas préciser comment faire par oubli (ça a été corrigé dans les versions suivantes)
* préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.

Le résultat est le même : c'est pas implémentable. Et c'est quelle ligne dans la doc OOXML qu'il est écrit que tel ou tel truc doit être utilisé et que c'est explicitement dis que ce n'était pas documenté ?
Ensuite OpenFormula n'était pas un vrai "oubli", c'était "on sait, mais on verra plus tard, pas le temps, faut le logo ISO au plus vite avant MS". Bref pareil, voir pire, le but n'est même pas le support d'un vieux truc non documenté par soucis de compatibilité, c'est un but purement marketing, on se dépêche pour avoir le logo avant le concurrent. Ca en dit long sur l'envie d'être interopérable avec le dis concurrent au passage.

Mais prenons un exemple plus parlant : ODF fait explicitement référence à la possibilité d'intégrer une applet Java. C'est pas normalisé, c'est pas à l'ISO. Tu vas me dire c'est quand même documenté, spécifié. Oui et ? L'implémentation de Java dépend d'une foultitude d'autres normes, ne serais-ce que, au pif, MPEG-4. Ensuite cette référence à Java aurait pu au moins avoir le bon goût de faire référence à la spec Java publiée par Sun, pour au moins savoir quelle version implémenter. Enfin si y'a également une vague référence à JDBC en bas du document, à noter que c'est dans un autre contexte que l'intégration d'Applet Java.

L'ODF est-il intégralement implémentable dans ces conditions autrement que par Sun ?

On gueule après MS qui fait référence à des formats non standard alors qu'à l'ISO il existe des équivalent normalisés, et qu'un format ISO devrait faire référence à d'autres normes ISO plutôt que réinventer la roue : ben pourquoi l'ODF ne fait pas référence à la norme ISO du CLR/C# ?
Bizzarement personne n'a rien trouvé à redire au moment du processus de normalisation ISO. Par contre le moindre détail similaire dans OOXML est décrit comme un scandale.

De la même manière dans l'ODF il est fait mention de JavaScript comme langage de script possible (à noter que la porte est laissé ouverte à n'importe quoi comme langage de script, avis aux implémenteurs du format qui vont s'arracher les cheveux si demain quelqu'un choisi autre chose que ce fait Sun) : aucune référence à la norme ECMA, et encore moins à la version qui serait bon d'utiliser.

Autre constat rigolo, on gueule après MS qui propose de faire référence à des trucs non documentés et des blobs binaires, notamment parcqu'il est possible d'intégrer des composants externe style OLE.... ben la norme ODF autorise l'inclusion de composant OLE.

Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
C'est donc bien une tentative d'élimination des autres acteurs du marché.
Oui MS tente le fast-track. Et ? C'est pas tant pour éliminer les autres acteurs du marché, s'ils avaient voulu faire ca, ils seraient pas passé par l'ECMA avant. Le fast-track, c'est pour avoir l'ISO le plus vite possible, étant donné qu'il y a un intérêt commercial à avoir le label "ISO". Ca n'élimine pas les autres acteurs, au contraire, cela leur fait prendre des risques supplémentaires, la preuve en est la rébellions de certains acteurs (IBM par exemple) qui pousse à un vote négatif.
Quand à l'ECMA, pourquoi Sun & IBM sont pas allez y faire un tour ? Personne ne les en a empêché que je sache. Non la réalité c'est qu'ils en avaient rien à battre, leur seul intérêt, c'est que l'ODF soit le seul a avoir le logo ISO pour mieux le vendre en tant que caution auprès des grands organismes.

, qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"

Bah ODF y'a des éléments qui n'étaient pas documenté (cf exemples plus haut), et le processus était aussi "ouvert" que celui de l'OOXML : à savoir viendez tous, faites 2 ou 3 modifs du moment que c'est compatible avec notre produit ; faites parler Sun avec OOo d'un côté, MS avec MS Office de l'autre, c'est kif kif bourriquot la même sitatution : MS s'en est rendu compte et à claquer la porte de l'OASIS, de l'autre côté Sun s'attendait au même comportement est a même pas été voir ce qui se passait à l'ECMA.

Tout ca pour dire que pour moi ODF n'est pas plus ou moins respectable que l'OOXML, les 2 ont leurs raisons d'êtres, ont beaucoup de défauts en commun, ont suivit un processus de normalisation à peu prêt similaire... Ah non, pour l'ODF il n'y a pas eu une bande blogger anti-MS à FUDer en permanence. Et c'est ce qu'essai de dire MDI, qui lui a le mérite d'être un développeur ayant déjà touché au domaine à travers le développement de Gnumeric.

sauf que cette fois il y a la doc (mal foutue, compliqué, partiellement documenté, etc...).
Un coup la doc est trop longue, un coup il manque des trucs, un autre coup elle est compliquée, bla bla bla.
Y'a sûrement du vrai dans ce que tu dis, mais pourquoi personne ne se plonge dans le foutu format ODF pour vraiment comparer ? Tout ce qu'on a, c'est une bande de geek libriste anti-MS qui répètes les arguments de 2 ou 3 personnes qui ont regarder avec une impartialité toute relative un seul format, le format à abattre : OOXML.
Ils auraient fait le même boulot sur l'ODF, on aurait pas vu des choses aussi absurde que l'absence d'OpenFormula dans la V1.
La vérité c'est qu'il y a une véritable campagne de dénigrement, et même si beaucoup de critiques techniques sont valables, elles ne justifient que rarement à elle seul la non-acceptation à l'ISO, sinon l'ODF n'aurait jamais dû passé. Par contre je le répète, ca peut être une bonne base pour améliorer l'OOXML.

De plus dans la vraie vie, je l'ai déjà dis plus haut, les développeurs constatent quoi :
- ODF est plus difficile à implémenter que OOXML, parcqu'OOXML se base sur des concepts largement connus (ca fait longtemps qu'on cherche à importer/exporter les .doc & co).
- l'ODF qui existe déjà depuis un bon moment, et aucune suite bureautique n'offre de support acceptable en dehors de OOo.

Bref, l'ODF n'a toujours pas atteind son objectif (enfin si, l'objectif profond était juste pour SUN d'avoir le logo commercial ISO, tout comme MS avec OOXML d'ailleur), y'a que les barbus pour y croire.

Allez bonne soirée, ce post sera de toute façon moinsser, je constate que le niveau des possibilités de discussion sur ce site ne se sont pas améliorer depuis la dernière fois.

Car OOXML, c'est une peinture XML autour de blocs binaires non documentés
Affirmation gratuite de quelqu'un qui n'a ni lu les specs, ni utilisé concrêtement le dis format.
Dans la vraie vie, je me suis amusé à tester certains export doc vers docx, dans la plupart des scénarios il n'y a pas le moindre bloc binaire dans le document XML généré.
Bon après c'est ma petite expérience sur des documents pas forcement représentatif (je me suis pas amusé avec des trucs style OLE), le fait est qu'il y a des situations où ton affirmation n'est pas vérifiée.

Après si tu prends un document ODF, tu peux très bien inclure dedans un bout de Java, tu peux aussi considérer cela comme un blob binaire (pas spécialement standardisé à l'ISO au passage, et qui a sa propose spécification qui évolue de manière entièrement désynchronisé avec ODF).

Sauf qu'on s'en fou de l'enveloppe si le contenu est toujours à la sauce MS, et que MS.
Et le format ODF qui est à la sauce Sun, c'est pas pareil ? Non bien sûr, Sun c'est le gentil, MS c'est le vilain. Argument de poids ca.

seul MS peut le lire, et dépend donc de la pérennité de MS.
Faut pas abuser, comme je l'ai dis c'est du XML, et faut pas être abruti pour comprendre la structure du document avec un éditeur de texte lambda, même sans la doc de référence. Donc même si certaines parties sont peut être mal documentées et difficilement implémentable, la plus grande partie d'un document "standard" est largement interprétable et exportable vers un autre outil que celui de MS. Bref, même si la pérénité de l'intégralité des documents n'est sans doute pas assurée sans le support de MS, c'est quand même mieux que le vieux .doc pas documenté, quoique t'en dise.
Ensuite la structure même XML du document permet de "récupérer" un document corrompu (erreur lors de l'écriture sur disque), avec n'importe quel éditeur de texte. Même d'un point de vue technique, les documents sont en soit plus pérenne qu'un .doc binaire.

autant normaliser les vieux .doc avec ton argumentation.
Ca aurait supposé un minimum de doc, ce qui aurait effectivement déjà été une grande avancée.

Et autant normaliser MS Windows, pour la pérennité aussi.
Si normaliser veut dire documenter obligatoirement, là encore ca ne peut être que bénéfique, même si ca veut rien dire "normaliser" un OS. Enfin bon comme toute comparaison, celle ci est plus que douteuse, on parle d'un format de données, et de la pérénité des informations représentées, pas d'un OS.

Oui, t'as raison en théorie.
Dans la pratique, l'ODF a été normalisé dans sa V1 sans OpenFormula, ce qui revient à ta réflexion :
" "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."
En fait c'était encore pire, c'était : pour respecter la norme ISO312, il faut y mettre... ce que vous voulez on a oublié de le préciser.
Concrêtement, le processus de normalisation de l'ODF a été laxiste parcque tous les partis étaient d'accord pour accepter son passage ISO, même MS.

Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.
Bah que je sache, l'ODF et l'OOXML suivent le même parcours à l'ISO, avec les mêmes acteurs potentiels. Tous peuvent participer à l'amélioration du format. Comme ils pouvaient d'ailleur également le faire à l'ECMA ou à l'OASIS auparavant.
Mais bon là c'est pareil, c'est la thoérie. Dans la pratique c'est uniquement un rapport de force et d'influence des plus grosses boîtes.

OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
Partant de là, l'ODF n'aurait jamais dû être normalisé, et je suis prêt à parier qu'une floppée de trucs standardisés à l'ISO ont dû avoir les mêmes entorses.

Cela dis, ca n'empêche pas de chercher à améliorer l'OOXML là où il est critiquer, du moment qu'il ne pert pas son intérêt premier : l'interopérabilité avec l'existant, ce que n'offre pas l'ODF.

Je corrige ma formulation :
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.


-->

C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est plus dangereux que les autres softs à utiliser sans la protection : tous les autres softs libres violent potentiellement une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.

Le coup de l'interoperabilite et de perennite c'est pas tres important.
Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML : être interopérable avec la principale suite du marché et apporter une "certaine" pérénité aux documents historiquement créé avec un format binaire alacon.

En cela OOXML est superbe : il autorise la traduction de vieux documents depuis un format non sûr vers quelque chose de plus pérenne dans le temps.

OOXML n'a pas le même but qu'ODF, non seulement ca justifie bon nombre de ses défauts (sans les excuser), mais sa justifie son existence et quelque part le fait qu'il ne fait pas double emploi avec ODF.

D'ailleur c'est rigolo de constater que niveau interopérabilité, il est beaucoup plus facile d'implémenter OOXML que ODF, tout simplement parcque OOXML se base sur l'existant qui est bien souvent déjà implémenté. C'est pas moi qui le dit, ni MDI, c'est un développeur de Gnumeric.

http://blogs.gnome.org/jody/2007/09/10/odf-vs-oox-asking-the(...)

En résumé : il y a 2 problématiques dans le support d'un format 'externe' : lire et interpréter le contenu d'une part, et le convertir dans le format natif de l'outil. OOXML cherche à résoudre le premier point : la lecture et l'interprétation sont largement facilité par l'utilisation de technos connues (XML + nombreux outils existant). En conservant la sémantique des vieux documents, il permet aux outils ayant déjà implémentés la conversion vers leur format natif de récupérer une bonne partie du code existant. ODF oblige à repartir "from scratch" en se basant sur la sémantique orientée OOo.

Donc d'un point de vue interopérabilité, si on parle de l'existant, OOXML a tout à fait sa place.

Alors oui, sinon le format a pleins de trucs "crades" qu'on aimerait plus voir, mais ils ont une raison d'être, et heuresement c'est en cela différent de l'ODF, l'OOXML a une raison d'exister : être crade mais dans un but valable : l'interopérabilité.

C'est pas l'avenir, mais une bonne transition.

Pour ce qui est de l'interopérabilité au sens monde des bisounours où on a un format unique Office lisible nativement par tous les outils sans problème, c'est un saint graal inaccessible, les formats Office étant par définition la représentation sous forme de données d'un ensemble de fonctionnalités, à moins de contraindre toutes les suites à avoir exactement les mêmes fonctionnalités et comportement...
Suffit de constater toutes les difficultés autour de l'ODF : tout le monde veut y ajouter ses modifs qui l'arrangerait dans sa suite, et personne ne veut d'un truc qu'il ne peut pas supporter. Au final statu-quo, on s'éloignera jamais vraiment de l'implémentation de référence OOo.

Alors un joli format qui au final ne sera vraiment interopérable qu'avec lui même ou un format crade qui permet d'assurer un minimum d'avenir à des milliards de documents existant...

et surtout, en reponse a la question si silverlight n'a pas de probleme de brevet: Not as long as you get/download Moonlight from Novell which will include patent coverage.
Oui, Novell offre une couverture juridique à ceux qui télécharge Moonlight depuis leur serveur. Et ? Protéger des utilisateurs contre un système de merde c'est mal ? Si ca te plaît pas, tu fais comme pour tous les autres softs libre que tu télécharges tous les jours sur sourceforge où ton repository deb/rpm : tu ne demandes pas de protection à Novell le jour où telle ou telle boîte t'attaque : ils t'offrent une protection, t'es pas obligé de l'utiliser.
C'est pas parcqu'ils t'offrent cette protection qu'il faut en déduire fallacieusement que le produit est dangereux à utiliser sans la protection : tous les autres softs libres violent une floppée de brevets (sans le savoir ou pas), ils sont tous potentiellement dangereux.

Alors oui, chercher à démolir l'OOXML auprès de l'ISO comme le fait IBM est ridicule, quand avant un format prétendu "universelle et interopérable" comme l'ODF a été normalisé alors qu'il n'était pertinemment pas implémentable dans la principale suite Office du marché.
Si l'ODF a le droit d'exister en tant que norme ISO (ce qui est largement compréhensible pour un tas de raison), l'OOXML a également le droit de l'être puisqu'il bouche largement des lacunes de l'ODF.

Après il faut utiliser le processus de l'ISO pour profiter d'une révision du format OOXML et l'améliorer là où ca peut l'être, sans chercher à singer OOo. En cela la proposition de l'AFNOR me paraît tout à fait pertinente : séparer ce qui est le coeur du format et les spécificités à l'interopérabilité avec l'existant.

"The data server, called "Evolution Data Server" is responsible for managing mail, calendar, addressbook, tasks and memo information"
J'ai cru aussi, mais nan, EDS ne gère pas les mails, Evolution les gère à part. (Ce qui est un peu con con question unification à mon goût).

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).

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é).

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.

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.

D'autant plus que c'est bien connu, C'est Apple qui fait des puces Core Duo, qui fabrique des cartes graphiques avec marqué "ATI" :)
Apple c'est un gros intégrateur, et dans leur package il y a un OS.
Le fait qu'ils vendent l'OS séparement montre clairement que la machine est décorélée de l'OS. C'est exactement comme un Windows face à un PC.
Le fait que Apple ne laisse pas le choix du matos (restriction supplémentaire) n'est pas une preuve d'abscence de vente liée.

but if you have arranged any sort of patent licensing that is prejudicial among the downstream recipients, that that's not allowed. ...
Et bien je leur souhaite bien du courage pour trouver la bonne formule, parcque en soit il n'y a aucun accord de licence du tout entre Novell et MS.
La FSF ferait mieux de dépenser cette énergie et ses avocats à combattre le système des brevets en soit plutôt que d'essayer de résoudre ses effets de bord : chacun essai de se défendre dans un système absurde.
On a gueulé après Novell parcqu'ils reconnaissaient explicitement les brevets logiciels, ben en parlant des brevets logiciels dans la GPL, la FSF fait exactement pareil.

Résumons: le rôle de l'université, c'est de former leurs étudiants sur les produits qui sont demandés par les entreprises, et surtout pas d'apprendre des concepts et d'être capables de les appliquer et s'adapter
J'ai jamais dis ca. Les concepts sont fondamentaux, mais encore faut il les appréhender (j'ai essayer de montrer qu'il fallait plusieurs applications concrêtes différentes). Ensuite tant qu'à prendre des exemples, autant prendre des exemples qui servirons dans la vie professionnelle.

Avec les boites qui font ensuite la promotion de ces même produits dans l'université, la boucle est bouclée.
T'as rien suivi de ce que j'ai dis. J'ai justement dit qu'il fallait mieux apprendre aux étudiants différentes technos dans un contexte éducatif, bref dans l'objectif de leur apprendre des concepts par l'exemple, et du même coup refuser les promotions de boîtes commerciales.
Dans la situation actuelle, les promotions commerciales sont certes mauvaises, mais souvent indispensable pour que les étudiants aient un minimum d'ouverture que leur enseignant refuse souvent de leur donner.

l'exemple des BDD est ridicule: il vaut mieux savoir ce que sont des transactions ACID et que certaines BDD ne les gèrent pas complètement, que de voir Access, SQL server et mysql.
Oui mais faut aussi savoir faire sans les transactions ACID ! Et rien de tel que d'utiliser un produit qui ne les gère pas. Tu remontres au passage leur utilité, bref au final tu appréhendes beaucoup mieux le concept, tu comprends son intérêt et ce qu'il apporte.

Sinon entre un adsys + des licences proprio et un adsys + des licences libre, je pense qu'on doit pouvoir faire des économies sur le deuxième point.
Non, parcque le premier adsys tu prends un kéké en interne qui sait clicktouiller, alors qu'un admin nux, c'est rare et cher.

Heu depuis quand les brevet logiciels existe en Europe?
Ca c'est la théorie. Essai de vendre un soft d'encodage MPEG2 par exemple sans payer les royalties. T'as beau être en Europe, amuse toi bien :)

Le DMCA, connais pas...
Oué enfin tu en conviendras qu'on ne peux pas regarder que notre nombril, et considérer les utilisateurs de LL dans leur ensemble, pas que les français :) Enfin tout ca pour dire que question légalité, le FUD tombe de partout quand il s'agit de dénigrer et faire chier les logiciels libres, qu'on le veuille ou non, c'est une réalité.

est celui de la dépendance (format proprietaires, bon vouloir des editeurs...).
Tout à fait, mais pour Linux tu peux poser les mêmes problèmes : les acteurs étant tellement rare (problème lié aux part de marché, donc faux problème mais problème réel quand même :) ) et tous les acteurs ayant tendances à proposer des solutions "maisons" ou "personnalisé", celui qui fait le choix d'utiliser des LL reste fortement dépendant d'une société de service particulière, voir pire, d'un geek barbu en interne qui a concocté ses propres scripts maisons :)
Si tu déploies du Microsoft, t'as que l'embarras du choix quant aux acteurs.
Certes, ce n'est pas du tout la même dépendance, mais dans les 2 cas t'es dépendant de quelque chose.
Perso je préfères encore la dépendance envers moi même sous Linux (vu que c'est moi l'admin de mes machines), mais en tant qu'entreprise, je sais pas trop ce qui me paraît le plus "indépendant".

On ne va pas supprimer les concepts vu en 3ème et 4ème pour apprendre un stupide produit qui utilise des concepts déja assimilés.
Moi je suis en train de t'expliquer qu'apprendre plusieurs produits conduisent justement à assimiler les concepts. Et tant qu'à apprendre des produits, autant utiliser ceux du marché, bref autant utiliser des exemples qui auront un intérêt sur le CV.

Pour appliquer SQL, pas besoin de le faire sur 18 BD différentes.
Non, mais au moins 2 ou 3. Pour voir qu'il y a des problématique différentes, que la syntaxe bouge, que certaines gère les transactions ACID, d'autre pas, qu'il faut en tenir compte. Le problème du mec qui s'est tapé un seul exemple, il croit avoir compris, il a retenu des trucs "par coeur", il a pas enregistré les concepts parcque de toute façon il est pas allé en cours ou alors il se remettait d'une cuite, bref il lui faut un 2ème exemple pour qu'il se dise "tiens je vais retenir que l'essentiel, le concept commun".

Bref rien de "ridicule", et je suis "sérieux".

Oué enfin tout ca pour dire que MS ne cherche pas forcement à assoire la position de l'OS Windows avec MSN Live Messenger : tu peux changer d'OS (au moins 1 en tout cas). (y'a pas besoin de ca)
Je penses qu'ils cherchent surtout à enfermer l'utilisateur dans "Windows Live", bref dans tous leurs services qui tourne autour de la nébuleuse "Live" : Hotmail, LiveSpace & Co. Y'a à mon avis pour eux beaucoup plus d'opportunités financières à enfermer les utilisateurs dans ce modèle. C'est en partie pour cela qu'ils ne veulent surtout pas ouvrir leur protocole.

Si t'es une entreprise, oui t'as besoin de raquer, si t'es un particulier, oui tu dois te mettre dans des situations illégales (DMCA, brevets logiciels, lecteur MP3, etc.).
(Cependant je suis bien d'accord qu'il faut combattre le fait que ca soit illégal :) )
Ah oui et puis bon, au final j'espère que le libre n'est pas qu'une question d'argent. Et le proprio n'est pas non plus une atteinte à ta santé.
Bref cette comparaison n'est pas forcement des plus pertinentes, surtout que je connais par ici beaucoup plus d'accroc au sens propre du terme à Linux qu'à Windows :-p