L'ECMA n'a fait qu'accepter une spec soumise par MS.
Au fait, les specs sont fournit par MS, Intel et HP, y'a pas que MS qui a son mot à dire.
Depuis les specs de la version 2.0 je te rappelle que Novell fait également partie intégrante du processus de normalisation.
Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Sauf que tu dis strictement n'importe quoi.
MS a normalisé la partie qui ne pourra plus bougé : les fondements, cad les libs de base et la VM : si MS casse la compatiblité avec cette norme ils cassent aussi la compatibilité avec toutes les applis .NET. Et si on regarde avec quelles difficultés ils conservent le support du win32 depuis des lustres, idem pour leur HTMLmadeIE (puisque tu aimes bien comparer avec le passé), alors on peut se dire que y'a pas de soucis à se faire concernant l'interopérabilité technique avec Mono.
De plus .NET n'est pas une simple évolution de win32, MS a pu repenser depuis 0 leur plateforme, ils y ont mis le temps et les moyens, c'est pas pour du jour au lendemain tout changer et faire chier le libre.
Je te rappelles aussi que Mono tourne aussi sous Windows, et que dans tous les cas les applis développées pour Mono resteront portables, quelque soit les choix de MS concernant son implémentation propriétaire.
Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML.
Je te rappelles que MS a fortement misé sur les technos XML (XML? XML Schema, XSLT, SOAP/Web Services, etc.) , notamment avec .NET, et qu'il est l'un des plus respectueux vis-à-vis de ces standards qui favorisent l'interopérabilité. Et jusque là tous leurs nouveaux produits vont dans ce sens.
Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
Pourquoi ? Parcque le support des .doc par OOo n'est pas parfait. Pour Mono, le support des standards et parfait et la compatiblité technique l'est aussi. Après chaque projet à ses libs spécifiques, Mono s'efforcant d'implémenter celle de MS.
Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Visiblement tu aimes bien dire n'importe quoi.
Si tu parles de ce qui tourne effectivement SUR Mono ou SUR le framework .NET, alors OUI, tout ce qui tourne sur le framework tourne sur Mono et inversement (auw bugs prêts bien sûr).
Ce qui n'est pas compatible ce sont certaines lib "natives" comme les WinForms ou les API Gnome dans Mono. Comme quoi y'a des incompatibilité dans les 2 sens.
Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens.
D'où l'idée de profiter du fait que MS les force à switcher vers .NET pour assurer un minimum d'interopérabilité dans notre monde Linux : tout le monde va y gagner, et personne ne va s'en plaindre.
Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.
D'où l'intérêt d'arrêter de FUDer sur la partie juridique, qui est du même niveau que dans toutes les autres solutions à base de LL.
D'où l'intérêt aussi d'avoir une boîte derrière pour soutenir commercialement le produit : Novell.
[^] # Re: Utilité de Mono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Interview de Miguel de Icaza par O'reilly. Évalué à 1.
Au fait, les specs sont fournit par MS, Intel et HP, y'a pas que MS qui a son mot à dire.
Depuis les specs de la version 2.0 je te rappelle que Novell fait également partie intégrante du processus de normalisation.
Mais si la mayonnaise prends, ils n'ont aucune raison de continuer. Une fois qu'on a conquis 99% du marché, l'ouverture et l'interopérabilité en s'en bat la courgette.
Sauf que tu dis strictement n'importe quoi.
MS a normalisé la partie qui ne pourra plus bougé : les fondements, cad les libs de base et la VM : si MS casse la compatiblité avec cette norme ils cassent aussi la compatibilité avec toutes les applis .NET. Et si on regarde avec quelles difficultés ils conservent le support du win32 depuis des lustres, idem pour leur HTMLmadeIE (puisque tu aimes bien comparer avec le passé), alors on peut se dire que y'a pas de soucis à se faire concernant l'interopérabilité technique avec Mono.
De plus .NET n'est pas une simple évolution de win32, MS a pu repenser depuis 0 leur plateforme, ils y ont mis le temps et les moyens, c'est pas pour du jour au lendemain tout changer et faire chier le libre.
Je te rappelles aussi que Mono tourne aussi sous Windows, et que dans tous les cas les applis développées pour Mono resteront portables, quelque soit les choix de MS concernant son implémentation propriétaire.
Un standard, c'est bien, mais rien ne les empêche de s'en écarter, comme pour le HTML.
Je te rappelles que MS a fortement misé sur les technos XML (XML? XML Schema, XSLT, SOAP/Web Services, etc.) , notamment avec .NET, et qu'il est l'un des plus respectueux vis-à-vis de ces standards qui favorisent l'interopérabilité. Et jusque là tous leurs nouveaux produits vont dans ce sens.
Il n'empêche que c'est l'implémentation de MS qui fait foi pour le .doc.
Pourquoi ? Parcque le support des .doc par OOo n'est pas parfait. Pour Mono, le support des standards et parfait et la compatiblité technique l'est aussi. Après chaque projet à ses libs spécifiques, Mono s'efforcant d'implémenter celle de MS.
Tout ce qui tourne sur Mono tourne sur le framework MS. L'inverse ne se vérifie pas.
Visiblement tu aimes bien dire n'importe quoi.
Si tu parles de ce qui tourne effectivement SUR Mono ou SUR le framework .NET, alors OUI, tout ce qui tourne sur le framework tourne sur Mono et inversement (auw bugs prêts bien sûr).
Ce qui n'est pas compatible ce sont certaines lib "natives" comme les WinForms ou les API Gnome dans Mono. Comme quoi y'a des incompatibilité dans les 2 sens.
Il n'y a qu'à voir le nombre de boites qui développent en VB pour voir que l'interopérabilité n'est pas l'objectif premier de la plupart des gens.
D'où l'idée de profiter du fait que MS les force à switcher vers .NET pour assurer un minimum d'interopérabilité dans notre monde Linux : tout le monde va y gagner, et personne ne va s'en plaindre.
Mono a des arguments techniques intéressants mais aucune boite ne voudra se risquer à parier dessus sans avoir des garanties sur sa pérénité.
D'où l'intérêt d'arrêter de FUDer sur la partie juridique, qui est du même niveau que dans toutes les autres solutions à base de LL.
D'où l'intérêt aussi d'avoir une boîte derrière pour soutenir commercialement le produit : Novell.