pasBill pasGates a écrit 16060 commentaires

Faut croire que non en fait, cf. http://blogs.msdn.com/brian_jones/archive/2008/01/16/mapping(...) la doc des formats binaires etait dispo depuis 2006.

Ce qui est marrant avec toi, c'est ta non comprehension totale du sujet qui fait que tu t'enfonces tout seul.

ODF supporte OLE, ce controle Word 2009 ou n'importe quel blob binaire, on peut l'inserer dans un document ODF tout comme dans le document OpenXML

Je te le redis, utilises uniquement des fichiers ASCII, parce qu'ODF ne remplit pas les criteres que tu demandes pour un format valable.

Non c'est toi qui ne sait pas lire, nulle part MS a dit qu'ils supporteraient le format dans un service pack de Mac Office plutot que dans la version de bas, je te mets au defi de prouver le contraire.

Ouaip, tout comme tu peux avoir ce controle OLE Word 2009 dans un document ODF.

Nope, c'est la board de Yahoo qui a donne une reponse officielle (cherches 5s tu trouveras l'annonce dans la presse).

Les actionnaires de Yahoo ont bien evidemment leur opinion, mais la position officielle de Yahoo c'est que l'offre de MS est en dessous de la valeur de Yahoo.

Il n'y a pas de confiance necessaire ici.

Sun paie et recoit l'action, si Sun ne paie pas, il ne recoit pas l'action. L'actionnaire n'a absolument pas besoin de faire confiance a Sun, le processus est garanti par le systeme.

Un truc non defini plus portable? Ouhous si je te donne un texte en sanskrit et que je ne te donne pas le dico pour le traduire tu vas y arriver je suppose? J'ai comme un doute

Merci de confirmer que tu es toujours incapable de comprendre une spec et ce qu'est un format.

Tiens c'est curieux moi qui croyait que la definition d'une norme etait justement pour eviter ce genre de risque. Tu me confortes dans mon opinion sur ce format.

Ah c'est dangereux ces choses la ?
Ben si tu veux mon avis mon cher, tu devrais jeter ODF a la poubelle, parce qu'ODF permet l'inclusion d'elements OLE.
Et tu sais quoi ? Cet element OLE, ca pourrait etre Word, Excel, ...

Pas un complot une tactique tres courante de ta boite comme les "petits bugs" dans IE. ActiveX etant disponible par defaut dans Windows (et probablement dans MS office 2008) cela sera plus simple a utiliser que un truc en java qui ne sera pas forcement installe par defaut. Enfin tu le sais tres bien et tu joues juste au lobbyste.

Plus simple a utiliser pour faire quoi ?
Et quid des gars qui ecrivent des documents ODF avec Java dedans et qui passent sur un systeme Windows sans Java ?
Si c'est pas un complot de Sun pour pousser Java ca... hein ? Ah marrant, ca marche dans les sens tes theories a la noix.

ps: t'as pas encore fini d'implementer le viewer de microsoft oxml pour un telephone quelconque? Puisque c'est tellement simple a faire suivant tes dires je voudrais voir ca a l'oeuvre :)

J'ai dit que c'etait possible, pas que c'etais faisable en 2 jours ni que j'allais le faire.
Mais au vu de ta comprehension de l'informatique et du developpement, je ne suis pas etonne que tu n'aies pas compris...

Non, des gens qui veulent du fric et qui en ont recu assez pour accepter de vendre.

Si tu crois qu'il y avait la dedans un ideal du libre, tu te mets le doigt dans l'oeil profond, c'etait une vente, pas une action de charite.

Donc on resume Microsoft oxml peut avoir des sortes de applet (comme ODF) mais ca peut etre en ActiveX ou en Java ou en ce que tu veux.

C'est beau ca comme description de format de document, c'est tellement precis que cela va etre simple a implementer...

C'est exactement ca: c'est bcp plus simple a implementer, suffit d'une interface pour appeler les controles, pas besoin de se farcir en plus le boulot pour integrer un controle precis d'une maniere particuliere, ils sont tous a la meme enseigne.

Donc la difference entre ODF et Microsoft oxml c'est que ODF lui precise quel est le langage pour faire cela tandis que Microsoft oxml laisse la porte ouverte a tous. Donc suivant les documents il faudra du activex, du java ou un autre truc. C'est encore moins portable que ODF du coup.

Au contraire, c'est PLUS portable. Il n'y a rien qui te lie a une techno particuliere qui ne serait dispo que sur X plateforme(s)

Si je comprend bien c'est encore un moyen pour Microsoft d'imposer sa techno ActiveX vu que l'on sait l'amour que ta boite porte a java.

Hahaha, tu m'expliqueras le rapport avec ActiveX mon cher, je ne vois pas ce qu'il vient faire la dedans, c'est un controle comme un autre, ca pourrait etre Flash aussi.

Clairement tu n'y comprends rien, tu as simplement vu les mots java et activeX dans la spec et est parti sur des suppositions foireuses sans meme comprendre ce que tu lisais.

Ta derniere phrase sur un suppose complot de MS pour imposer ActiveX est a mourrir de rire tellement elle est stupide, ActiveX n'est pas traite differement des autres et n'est pas mis plus en avant non plus.

Ils ne font pas partie de la norme.

Que tu sois incapable de comprendre une spec c'est ton probleme.

Nulle part dans la spec d'OpenXML il est mentionne qu'une implementation doit supporter Java ou ActiveX, ces 2 technos ne sont donnees qu'a titre d'exemple de controle.

Pour etre precis, la spec ne mandate AUCUN controle specifique, c'est laisse au libre choix de l'implementation. Elle mandate simplement le support des controles.

De nouveau, tu ne comprends rien a ce qu'est une spec.

La spec ne mandate pas le support d'une quelconque technologie, que ce soit Java ou ActiveX. Ces 2 sont donnes a titre d'exemple dans la spec, nulle part il est specifie que l'implementation doit supporter ActiveX ou Java.

La spec mandate le support de controles externes, et c'est tout. Les controles supportes sont laisses au libre choix de l'implementation.

Et c'est LA grande difference avec ODF sur ce point.

Faut te mettre a jour, ca a change depuis 2005 :

http://www.microsoft.com/interop/osp/default.mspx

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?

A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

C'est principalement une question de prix. La transaction c'est 50% cash / 50% action

Tu remarqueras que la reponse de Yahoo c'est "vous sous-evaluez le prix de Yahoo", bref, ils veulent plus de fric.

Tes 2 paragraphes sont un gros caca nerveux qui n'a rien a voir avec la discussion.

La realite, c'est que les 2 standards ont exactement la meme assurance.

La realite c'est que les 2 societes sont aussi orientees fric l'une que l'autre et qu'il est donc impossible de leur faire confiance.

Tous tes delires sur le fait que MS c'est des maichants et que Sun est un chevalier blanc on s'en tape, c'est la realite qui compte.

Le truc etant qu'a part les moutons du libre, personne ne fait confiance a Sun non plus.

Avec une "legere" difference tout de meme... koffice il y a 3 developpeurs et meme pas a plein temps. Je te trouve tres tres rigolo de comparer un suite office developpe par 3 personnes a temps partiel et une suite office developpe par des centaines a plein temps. Tu veux dire que les devs du libre soit (x*100)% meilleur que ceux de ta boite :)

Oh mais rassures-toi, je compares pas KOffice a Office pour Mac, on sait tous les 2 qu'Office pour Mac est bcp plus complet que KOffice et bcp plus compatible avec Office Windows que KOffice ne l'est avec OO.

Le probleme avec KOffice c'est toi qui le cree, si tu veux t'amuser a compter KOffice comme une suite office a part entiere et le mettre dans le meme sac qu'OO et MS Office, fais le, mais un soft on le compare sur ses capacites, pas sur le nombre de gens qui le developpent. L'utilisateur il s'en fout de savoir si il sont 3 ou 300, soit le soft fait ce qu'il veut, soit il ne le fait pas.

je vais tout de meme repondre a cela. T'es tres gentil mais nulle part dans la doc de ODF il est dit que le java qu'il est possible d'inclure dans ODF comprend le JVM+framework. En l'occurence cela ne concerne que l'inclusion d'applet et il me semble bien que, curieusement, les applets java fonctionne sur des telephones portables.

Perdu, comme je te l'ai montre sur la page de Sun directement dans ce commentaire : http://www.linuxfr.org/comments/903716.html#903716

Les telephones portables et la plupart des PDAs ne supportent pas les applets, car ce support n'est dispo que dans le Personal Profile.

En ce qui concerne microsoft oxml et les plateformes mobile:
1) le meme probleme que java existe a cause de activx

Il n'y a aucun ActiveX specifie dans OpenXML, je te mets au defi de prouver le contraire

2) la theorie c'est un chouilla different de la pratique comme cela a bien ete montre avec tous les formats binaires de microsoft successif ayant soit-disant une compatibilite parfaite avec le format precedent ou encore avec Vista qui devait etre mieux que tous les OS ayant existe. Le jour ou toi ou ton compere pbpg nous montrera un telephone ayant des caracteristitique de fevrier 2008 (je soupconne que dans quelques annees les telephones portables auront autant de memoire voir de puissance que certains pc aujourd'hui) supportant une suite office supportant microsoft oxml on reparlera du probleme de la dependance de java dans ODF. D'ici la theoriquement la teleportation d'etre humain existe, theoriquement.

Comme je te l'ai deja dit, nulle besoin d'implementer une suite office, si tu veux implementer un viewer(ce qui est extremement utile), t'as besoin de bcp moins de ressources.
Le truc etant que ton viewer ne sera pas conforme ODF sans le support Java, mais pourra etre conforme OpenXML vu qu'il n'y a aucune techno empechant son implementation sur un PDA/smartphone.

Tu aimes raconter n'importe quoi. Reste dans ton domaine, tu es bien plus brillant.

Il existe des smartcard qui supportent java depuis longtemps et crois moi, elle n'ont pas quelques centaines Mo de RAM mais quelques centaines Ko.

En parlant de raconter n'importe quoi, je t'invite a aller lire la spec d'ODF, qui comme tu le verras mentionne clairement qu'il faut supporter des applets Java.

Ensuite, tu vas sur le site Java de Sun pour tout ce qui est mobile : http://java.sun.com/javame/technology/index.jsp et tu verras que les applets ne sont supporte que dans le Personal Profile.
Resultat, pas de support d'applets sur telephones mobiles et la plupart des PDAs, et bien sur, pas de support d'applets sur ta smartcard.

Java nécessite une infinité moins de puissance que n'importe quelle traitement de texte. Tu as déjà vu une suite Office sur un téléphone portable ? Parce que Java y existe depuis longtemps.

Tu sais ce que je peux faire sur mon smartphone ? Je peux lire des documents PDF par exemple.
Je pourrais tout a fait avoir un viewer pour OpenXML, pas besoin d'implementer une suite Office complete.
Le truc, c'est que je ne pourrais pas avoir un viewer ODF 100% standard car il n'y a pas de support des applets Java...

Cela permet aussi d'avoir un code en moyenne 20% plus rapide par exemple...

Tout depend de ce que tu fais. Etre 20% plus rapide pour un soft qui passe la plupart de son temps a attendre que l'utilisateur presse les touches du clavier c'est sans interet.

Ils n'ont jamais parle de le mettre dans un SP.

Quand a changer des trucs, probablement autant qu'avec OO et ODF aujourd'hui si tu veux mettre une formule dans ton document...

Resultat, je te conseille d'utiliser des fichier ASCII.

Java applets are described as native objects in the OpenDocument specification (§9.3.4). This means any full implementations will require a Java Virtual Machine present from within the application. However, conformance to the standard does not require a full implementation.

source wikipedia

Super !!

Et tu sais quoi ? Si tu lis la spec d'OpenXML, tous ces trucs dont tu te plains (autoSpaceLikeWord95, ...) sont optionels aussi, pourtant tu ne t'es pas prive de dire que cela rendait impossible une implementation.

Comment se faire prendre a son propre jeu...

T'as beau le repeter c'est faux.

J'ai pas besoin de le repeter, c'est un fait etabli, suffit de lire la spec pour s'en rendre compte.

Tu regardes la spec d'OpenXML et tu n'y verras aucune technologie lourde.

Tu regardes la spec d'ODF, et tu verras qu'il est clairement specifie qu'il faut pouvoir faire tourner des applets Java.
Ensuite, tu vas sur le site Java de Sun, et tu verras que les applets Java ne sont supportes qu'a partir de certains types d'appareils(gros PDA), pas en dessous.
Resultat, tu ne _peux pas_ implementer ODF en te conformant au standard sur des plateformes plus legeres.

Quand au ActiveX, inutile d'y repondre, nulle part la spec OpenXML parle d'ActiveX.

ah ah ah voyons voir ah oui mon telephone a java a l'interieur et il a vraiment rien comme memoire.

Non il a Java Mobile, mais visiblement une fois de plus (difference CPU 32<->64bit, etc...) tu ne comprends rien au sujet.

Le support des applets est uniquement present dans le Personal Profile, qui n'est pas supporte sur les telephones mobiles et petits PDA.

http://developers.sun.com/mobility/midp/articles/models/

On the J2ME platform, applet support is currently found only in the Personal Profile.

cf. http://java.sun.com/javame/technology/index.jsp pour le support.

Enfin de tout de facon tu parles de ODT avec Java a l'interieur et que cela est trop lour je pense que le meme argument est tout a fait utilisable pour un document ppt (je connais pas l'extension pour microsoft oxml) avec une video de plusieurs dizaines de megs a l'interieur. Ca marchera pas comme un document ODT avec du java a l'interieur ou une video.

De nouveau, rien a voir.
Sur Windows Mobile, Symbian, ... je peux creer une implementation 100% conforme d'OpenXML. Qu'il ne puisse pas lire tous les fichiers par manque de ressources c'est un autre probleme, tout comme Office ne pourrait pas ouvrire un document de 1Go sur une machine avec 128Mo de RAM.

Par contre avec ODF, ton implementation elle n'est pas conforme, car il manque un element. Il est techniquement impossible d'implementer un lecteur ODF 100% conforme sur ces OS.

Tu remarqueras en passant aussi qu'OpenXML ne mandate pas un format de video particulier...

Ton argument sans aucune preuves vu qu'il n'existe aucune implementation de microsoft oxml sur des configs tres legeres est assez ridicule.

Fais seulement, trouves moi une techno dans OpenXML qui force l'OS hote a avoir des ressources serieuses pour etre conforme. La spec est la, fais donc.


ps: va faire tourner un microsoft office 12 sur un pentium 166. C'est pas faisable, OOo ca le fait meme avec java, c'est pas un foudre de guerre loin de la mais cela demarre et est a peu pres utilisable.

Encore une fois, tu melanges spec et implementation. A croire que tu n'y comprends rien.

Je peux t'ecrire un soft bien plus leger qu'Office(ou OO), ayant une utilite bien particuliere (afficher uniquement par exemple), qui lui a besoin de bcp moins de ressources qu'Office/OO.

Avec ODF, ce soft ne sera pas conforme si il ne supporte pas Java, ce qui disqualifie a peu pres toutes les plateformes mobiles, avec OpenXML pas de contrainte de ce type.

Va lire des bouquins d'informatique, prends des cours, ... je sais pas, mais apprends la difference entre une implementation et une spec, c'est pas sorcier.

sur quel plateorme java n'est pas implementable?

Plateformes mobiles au hasard. T'as pas l'air de comprendre que le probleme n'est pas que le code n'est pas portable/ouvert/... mais qu'il faut des ressources pour faire tourner une JVM complete et son framework.

tiens pourtant mon telephone portable a java dedans et c'est un truc tout basique... Ton "argument" est assez foireux car tu n'amenes strictement aucune preuve de tes affirmations.

De nouveau, tu ne comprends rien au niveau technologique. Java c'est un ensemble : JVM+framework.
Ce qu'il y a dans ton telephone mobile, cest Java Mobile, pas le Java que tu as sur ton PC. Le framework est different et limite.
Essaie de faire tourner Eclipse sur ton mobile qu'on rigole...

Mais oui mon cher du coup vous vous tapez des trucs style chroot avec des redondances de librairies etc. Je comprend mieux la dizaine de gigas pour installer un systeme nu Microsoft Vista.

Ah oui c'est vrai, Linux ne fait pas cela lui hein ?

Ah si tiens, ils font de meme... Rigolo non ?

ODT c'est pas portable car java existe pas partout
microsoft oxml n'existe que sous x86 windows et macos X mais ca c'est portable.

ODT n'est pas totalement portable car Java _ne peut pas exister_ partout.

OpenXML, bien que n'ayant que des implementations sur x86 sur plusieurs OS cependant est portable car _il est possible_ de l'implementer sur les autres plateformes.

Pour t'aider a comprendre : Il est possible de supporter OpenXML sur un systeme avec qqe megaoctets de RAM et un cpu peu puissant, avec ODF par contre, tu ne peux pas avoir une implementation conforme, car ton systeme n'est pas assez puissant pour supporter Java.

Visiblement t'as toujours du mal a comprendre la difference entre ce qui est fait, ce qui est faisable, et ce qui n'est pas faisable.

Apres j'ai gentiment devie sur le x64 car TU as parle de support sur autre plateforme. Cela me fait rigoler que ta boite soit toujours aussi incapable de sortir des softs x64. Tu veux des exemples d'utilite? Pour un tableur faire des calculs plus precis a oui zut je comprend maintenant ta remarque et pourquoi c'est inutile pour Microsoft Office vu comme excel est doue pour les calculs... :)

Merci de passer pour un idiot complet.
La difference entre un CPU 64bit et un 32bit ce n'est pas de faire des calculs sur 64bit, les CPU x86 d'hier en etaient deja capable, ca donne la possibilite d'addresser 2^64 bytes en RAM a comparer aux 2^32 bytes des CPU x86 .
Bref, aucune difference en precision de calcul, ca te permet juste d'avoir un document Word ou Excel de >3Go en RAM si l'envie te passe.

Si tu comprenais un minimum l'informatique mon cher, tu aurais compris que MS n'a pas sorti Office pour x64 alors qu'il a sorti Exchange, SQL Server, ... pour x64 car c'est totalement inutile. Personne au jour d'aujourd'hui n'est limite dans son utilisation d'Office par la limite des 4Go de RAM du x86

Dis moi, tu fais expres de ne pas comprendre hein ?

Java, ca a beau etre ouvert, GPL, libre, etc... ca n'en fait pas moins une dependance extremement lourde et inutile. Implementer Java sur une plateforme requiert que la plateforme ait une quantite de ressources CPU/memoire/... non negligeable, par sa spec, Java limite les plateformes sur lesquelles il est implementable car certaines de ces plateformes ne peuvent tout simplement pas l'implementer efficacement par manque de ressources.

OpenXML n'a rien de cela, tu remarqueras qu'il n'y a aucune dependance sur C# et sa machine virtuelle par exemple.