benoar a écrit 4272 commentaires

Google arrive à prédire des épidémies de grippe plusieurs jours avant les systèmes traditionnel de santé vigilance. (https://www.google.org/flutrends/) Je trouve ça intéressant (et dans ce cas les infos peuvent être anonymisé). Tu peux gagner des informations précieuse sans forcément tomber dans la pire dictature.

Oui, c'est intéressant, mais si ça nécessite de violer la vie privée des gens, non, je préfère m'en passer. C'est comme ça qu'on se retrouve dans des situations de « blocage » où on n'arrive même plus à faire appel à la capacité de réflexion des gens : « mais c'est si pratique ! ». Oui, c'est clair, et en France, juste avant la CNIL, on se disait que ça serait vachement plus pratique d'avoir un numéro unique d'identification pour tous les citoyens : les déclarations seraient vachement simplifiées, etc. Mais on a refusé parce qu'on a estimé que ça serait trop dangereux.

Tout dépend comment cela est fait, par qui et dans quel but. Le qui étant le plus important (le but et le comment découlant souvent du qui).

Effectivement, le débat est là. Et donc, je dis : concentrer les données personnelles des gens à un endroit contrôlé par une entité, forcément ça va amener les gouvernements à vouloir l'utiliser pour faire de la surveillance. En fait, non, c'est même pire que ça : c'est déjà de la surveillance inacceptable par une entité privée, mais les gens s'en foutent parce que « c'est si pratique » ! Je ne vais pas ressortir le dictons sur ceux qui veulent bien abandonner un peu de liberté pour un peu plus de practicité…

En tous cas, pour moi, ça n'est pas « moins grave » si c'est FB ou Google. Ça revient au même pour moi. Et le but, bah, ça va être dur de garder des choses qui donnent tant de pouvoir dans un but vertueux. Un autre paramètre très important pour moi est le comment : est-ce que c'est conçu de manière à limiter les abus. Si ça n'est pas d'origine prévu pour ça, et que ça laisse la possibilité, c'est mauvais.

Après on fait un calcul de risque par rapport et on estime que le risque d'une arme est plus élevé que le risque d'un couteau et donc on en contrôle leur accès (permis d'arme).

Non, le « calcul du risque » c'est une vision libertarienne qui est une réécriture de comment ça s'est passé en France. Aux US, qui sont très libéraux et adeptes du calcul du risque, ils ont décidé que ça valait le coup.

Qui estime qu'internet fait plutôt le bien ? A part quelques personnes convaincu que c'est la troisième évolution majeur de l'humanité après l'écriture et l'imprimerie, y a malheureusement beaucoup de personne qu'y le voit internet d'un mauvais oeil (Un repaire de pedo-nazi-terroriste-pirate incontrôlé).

Oui enfin quand-même, va dire aux gens ce qu'ils feraient sans, je pense qu'une bonne partie te dira que ça leur apporte du positif dans leurs vies. Oui, une autre bonne partie (pas forcément exclue de l'autre) veut qu'on contrôle beaucoup plus Internet, mais je ne pense pas que la majorité veuille une surveillance telle qu'elle est proposée dans cette loi.

En passant, je viens de lire encore un très bon article sur InternetActu à propos du pouvoir qu'apporte la connaissance des données personnelles : http://internetactu.blog.lemonde.fr/2015/03/20/demain-comment-saurons-nous-comment-on-nous-manipule/ C'est sur le livre de Bruce Schneier, qui est encore une fois en plein dans le vrai.

Je ne vois pas en quoi. Je suis utilisateur de Gmail, donc j'accepte que Google récupère des infos sur moi, les vende, les utilise, etc… Mais cet accord se limite aux informations que je veux bien donner à Google.

Ça c'est ce que dit le contrat. Ce que je dis c'est sur ce qu'il se passera forcément au final dans ce style d'accord déséquilibré, car tu te fais bouffer par Google sans t'en rendre compte (ce qui peut t'excuser un peu), mais je me disais que tout le monde l'avait peut-être quand même dans un coin de sa tête, d'où la qualification d'hypocrite. En fait, si tu n'es pas hypocrite, tu es drôlement (et dangereusement) naïf.

Je ne vois pas pourquoi refuser que quelqu'un d'autre récupère d'autres informations sur moi serait hypocrite. Surtout que là, j'ai rien en échange.

Parce que c'est trop beau pour que quiconque d'un peu puissant le laisse passer : Google est en train de bouffer toutes les autres formes de pouvoir, et ceux-ci ne vont pas se laisser faire. Ils voudront donc des capacités équivalentes. Ça n'est pas en disant « je ne le veux pas » sur un bout de papier que tu pourras changer cet état de fait. Ou alors tu es drôlement naïf (bis).

Je ne me rappelle pas d'avoir donné mon accord pour qu'on surveille les lybiens, les syriens ou autres. Dans ta phrase, "on" ne signifie pas "nous", mais "ils".

Tu as accepté le jeu électoral qui a élu ces personnes. Même si ça n'est pas une responsabilité directe, c'est une certaine responsabilité quand-même.

Quand ils ont espionné les lybiens, […] syriens, […] tunisiens, […]

Ah oui, on voit le beau résultat aujourd'hui. Je pense qu'on trouve toujours de l'Amesys (boîte française pour rappel) dans ces pays aujourd'hui.

Quand mes propres dirigeants veulent m'espionner, laisse moi le droit de me défendre contre eux sans me traiter d'hypocrite. Merci d'avance !

Mais essaye de te défendre, je t'y encourage ! Je dis juste que si tu espères garder tes avantages du big data tout en arrivant à combattre l'espionnage de masse, je pense que tu te trompes gravement.

Il y a une différence entre "vouloir" et "s'arroger le droit de".

Oui, dans la théorie. Dans la pratique, j'essaye de montrer comment c'est irréaliste, vu la manière dont ces systèmes sont architecturés.

De plus, comme tu l'as dit, les sociétés utilisaient les données qu'on leur a donné volontairement.

Ça aussi ça mériterait un autre débat, sur la volonté réelle des gens qui participent à des réseaux sociaux.

Non une technologie n'est ni bonne ni mauvaise. On peut faire des choses géniales avec les big data comme de la surveillance de masse. Le problème n'est pas les big data mais à ce qu'on en fait.

La vision manichéenne libertarienne américaine mise à part, non, le big data appliqué aux données personnelles n'est pas une technologie neutre : mettre toutes les données personnelles de tout le monde dans un endroit pour les exploiter, ça mènera forcément au pire.

Pour l'analogie, en France, on autorise les couteaux même si ça peut être dangereux car dans l'énorme majorité des cas, les gens les utilisent bien, et qu'on peut difficilement faire un Hiroshima avec un couteau. Par contre, on interdit les armes (qui ne sont pas « ni bonnes, ni mauvaises », donc) car on estime que c'est beaucoup trop facilement utilisé pour faire le mal (oui, je caricature un peu).

Internet est une technologie qui a été conçue de manière a-centrée, en ayant une bonne répartition des pouvoirs. On peut quand même faire des choses mauvaises avec, mais globalement on estime que ça fait plutôt le bien. Par contre, l'exploitation « intelligente » des données personnelles, massivement, par un nombre réduit d'acteurs, c'est fondamentalement mauvais. Perso, je ne vois que très peu de résultat positif à ça (OK, c'est sûrement car je n'utilise pas les réseaux sociaux, mais je n'ai pas l'impression de manquer beaucoup de choses).

Au vu des commentaires, il y a beaucoup d'incompréhensions. Je commence avec ton commentaire : non, ce que j'ai écrit n'est pas une justification de ce que fait le gouvernement. C'est juste une explication du pourquoi ça arrive, quand on réfléchit un peu aux équilibres politiques en présence. S'imaginer qu'on peut avoir un Facebook gentil et que le gouvernement ne l'exploitera pas, c'est être un gros bisounours : bien sûr que toutes les technologies faites pour concentrer fondamentalement le pouvoir en un point (chez FB) va attirer le pouvoir politique en place. C'est nul, mais c'est une vérité politique à laquelle il est difficile d'échapper quand on étudie un peu l'Histoire.

Et clairement, je ne peux pas opposer LibreOffice à Google Docs. La possibilité de travailler en temps réel à plusieurs est ce qui attire dans ces plateformes. Aussi le fait qu'ils n'ont pas besoin d'aller télécharger et installer un logiciel. Je voudrais pouvoir proposer WebODF par exemple, mais ce genre d'applications Web reste chiant à installer, même pour quelqu'un qui maîtrise un peu l'informatique.

Ça a toujours été le même problème avec le Libre : si tu essayes de le faire valoir pour des critères autres que sa liberté, on pourra toujours trouver mieux en proprio. Tu n'as aucune chance de favoriser le Logiciel Libre et le respect de la vie privée si tu te mets comme objectif de pouvoir présenter un logiciel aussi bon techniquement que les alternatives proprios.

Essayer de dire à quelqu'un qu'il aura aussi bien en Libre est un mensonge : il faut être honnête et lui expliquer que ça sera un peu moins bien, mais au moins il sera libre et sa vie privée sera respectée. On ne peut pas avoir le beurre et l'argent du beurre.

Sur les photos, on voit que c'est un ATmega32U4… pourquoi pas un bon petit ARM 32bits, s'il y a ARM qui soutient le projet en plus ? La toolchain et le modèle de programmation seraient tellement plus sympas…

les conteneurs et les VM classiques se gèrent de façon trop différentes pour qu'une couche d'abstraction comme libvirt (orientée gestion de VM classiques)

Mouai, je ne suis pas convaincu, je pense qu'il n'a pas beaucoup touché à libvirt-lxc pour dire ça.

Par exemple, tout ce qui concerne la gestion du matériel émulé pour les VM n'a pas lieu d'être pour les conteneurs. Il y aurait donc une grosse partie de l'API et par conséquent de la GUI associée (virt-manager par exemple) qui ne servirait à rien dans le cas des conteneurs.

Effectivement, et ça s'intègre quand même très bien au modèle libvirt.

A l'inverse, il y a des choses spécifiques aux conteneurs (comme transférer une interface réseau, ou n'importe quel périphérique de l'hôte) qui n'existeraient pas ou qui seraient spécifiques et inutiles pour les VM.

Mais qui sont quand même présentent dans libvirt ! (bon, pas directement pour l'interface réseau, mais je ne vois pas de cas où ça a un intérêt vu les possibilités réseau de libvirt)

Franchement, il y a déjà à peu près tout ce dont il parle dans libvirt-lxc. C'est juste qu'ils veulent se différencier et faire un truc à part, bien intégré à OpenStack (déjà, ça devrait être signe que le NIH point son nez). Il faut lire l'annonce d'Ubuntu pour LXD http://www.ubuntu.com/cloud/tools/lxd pour voir comment ça sent le bullshit à 100 mètres.

Du coup, même si c'est effectivement plutôt Canonical qui pousse au cul pour LXC/LXD, cet abandon de support par Red Hat ne me fait pas pour autant penser qu'ils se désintéressent de LXC.

Bah, je ne comprends pas du coup pourquoi ils laissent tomber ça dans RHEL, sachant que je n'ai pas vu de nouvelle upstream du projet libvirt. C'est assez étrange.

Oui, libvirt a son propre « driver », mais d'un point de vue extérieur, il a toujours l'air maintenu dans le projet libvirt. RedHat a-t-il des informations supplémentaires là-dessus ? Vu que libvirt est géré par RH, j'aimerais bien savoir ce qu'il en est de l'avenir de ce driver.

Je peux comprendre qu'avec Docker ça fasse un peu redondant, mais pour moi c'était une bonne alternative qui a quand même ses différences et ses atouts.

Bah ca fait 20% en plus?

Pour moi ça n'est pas « largement » plus cher à +20%, mais bon, chacun sa définition…

pourquoi dis tu que ces écran sont bien merdique?

Écrans TN, déjà, ça va direct à la case poubelle pour moi. N'espère pas les utiliser en vertical non plus. Et ce sont des entrée de gamme.

Mais bon, pareil, c'est juste mon avis.

ils ont été recrutés sans pouvoir le dire (interdit par le contrat)

Franchement, ça me fera toujours halluciner que ce genre de chose soit légale. D'autant plus dans un pays qui se veut le berceau de la liberté d'expression…

Puisque pour 2 écrans et un pied on est largement plus chère que ce soit chez rueducommerce, amazon, …

Heu… en suivant le premier lien, par exemple, on est à 300 € au lieu de 365 € si tu prends les même séparés, ce qui n'est pas « largement » plus cher je trouve.

Si tu vois du beaucoup plus cher, à mon avis, c'est que tu ne compares pas avec les même écrans. D'un côté, c'est vrai que ceux du pack que tu présente ont l'air bien merdiques. Si tu veux deux bons écrans, tu on auras pour le double je pense.

Perso, j'aime bien logcheck qui me fait un rapport quotidien (si besoin) des choses « bizarres » qui arrivent dans les logs. Son inconvénient par contre est qu'il demande de mettre à jour les règles assez régulièrement si on ne veut pas en arriver à ne plus le lire parce qu'il rapporte trop de choses : il faut lui dire d'ignorer les choses qu'on sait bénignes au fur et à mesure.

Ça n'est pas de la sécurité préventive, mais c'est toujours utile.

J'ai beau avoir fait du latin, je comprends que de chique.

« que de chique » ?! Faut qu'il retourne à l'école l'gadjo ! http://fr.wiktionary.org/wiki/que_tchi

Je n'utilise pas, mais ça ressemble beaucoup à mr : http://myrepos.branchable.com/

Je connais encore mal le domaine, mais il me semble que des OS pour STM32 (ou autre micro-contrôleur), on en trouve à la pelle¹… Le tiens a-t-il quelque-chose de spécial en dehors de ce qui existe déjà ? Ou c'est juste pour s'amuser ?

En passant, je mets un référence vers un « OS » un peu différent, basé également sur un STM32F103, qui ne gère que l'ordonnancement de threads et c'est tout : Chopstx https://gitorious.org/chopstx/
Il a été écrit pour le projet GnuK http://www.fsij.org/gnuk/, qui utilisait auparavant ChibiOS/RT http://www.chibios.org/, un truc un peu plus lourd. Je le trouve intéressant car il n'essaye pas de réinventer une couche d'abstraction.

1 : http://en.wikipedia.org/wiki/List_of_real-time_operating_systems

Un facteur qui puisse expliquer ce choix: est ce que l'on peut debugguer du XSLT?

Pas super facilement en effet. Je comprends que ça joue un peu contre lui. Perso, je le fais avec les messages la plupart du temps assez clair de l'interpréteur (xsltproc) et des <xsl:message> placés aux endroits stratégiques. Mais ça n'est clairement pas idéal.

En fait le problème que j’avais eu à l’époque avec Xslt, c’est que le découpage fonctionnel est beaucoup moins évident à voir et à faire que dans un langage impératif. Or, le découpage fonctionnel, c’est un des critères principaux de lisibilité.

C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.

L’autre gros soucis, c’est qu’il est facile d’avoir des effets de bord globaux sans le faire exprès --> ça, c’est terrible pour la maintenance. À chaque modification de la feuille, tu pries (et en plus, on n’avait pas TUs corrects derrière).

Mmhh… je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.

En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.

On retrouve le même genre de choses chez prolog, erlang (je crois), ou dans une certaine mesure les templates c++.

Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives… je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres… bon, je les connais moins aussi).

C’est très pratique pour certaines choses, très puissant, mais quand on en abuse, c’est facile d’arriver à des choses totalement illisibles.

Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de “Domain Specific Language” pour le traitement d'arbres.

LibreOffice a quand même pas mal de tests autour de l'import des doc/docx et ça m'étonnerait que Miklos ait accepté une solution qui introduise des régressions.

Le code qu'il a enlevé n'a à priori pas introduit de régression, c'est seulement du code qui a été jugé « inutile » parce que les fonctionnalités n'étaient (apparemment) que peu utilisées dans les documents créées par MS Office, ou alors pas implémentées par MS, d'après ce que j'ai compris.

Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…

Tiens, je viens de penser qu'on pourrait utiliser des décorateurs avec des expressions XPath pour faire comme du XSLT… marrant comme idée.

• deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
• peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé

Je n'ai pas trop eu le problème, je me suis limité à XSLT v1, la v2 étant peu supportée par des outils libres. J'ai ressenti certains manques des fois, mais rien de trop important.

• la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)

Moi je la trouve intuitive… Et du coup, c'est l'occasion de se mettre au fonctionnel !

Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte

Oui, mais on aborde le classique problème : doit-on utiliser des outils de merde (dans ce contexte) pour être accessible, ou doit-on demander à avoir un minimum d'initiation afin de pouvoir utiliser des choses plus adaptées, et sur le long terme, beaucoup plus efficaces ? Sur linuxfr, je pensais qu'on hésitait moins sur l'investissement dans des outils « complexes » si le jeu en vaut la chandelle…

Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)

Pour la génération de texte, effectivement, ça aiderait (c'est un handicap de XSLT aussi : il est plus à l'aise dans la génération de XML que de texte brut) ; j'aime beaucoup Jinja2. Par contre, pour le parsing de XML d'entrée, ça n'aidera en rien, et c'est surtout là-dessus que Python pêche, je trouve.

plusieurs dizaines de lignes de code en tout, soit un facteur 10 par rapport à un langage généraliste.

Oui enfin dans ce cas, la bonne solution est d'en faire une bonne bibliothèque, comme pour les autres langages… mais c'est vrai qu'à ce niveau (ressources externes en extensions XSLT), le langage est malheureusement peu pourvu.

Mais le jour où l'on décide de normaliser certaines valeurs XML en croisant avec une base de données, alors la feuille XSL devient un boulet.

C'est vrai que dans ce genre de cas, je comprends que XSLT ne soit plus adapté.

Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…

s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.

Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.

j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça

Ouch, ça fait mal, oui.

• le manque d’opérations triviales (formatage de dates par exemple)

Bon, ça c'est vrai que ça semble un petit peu limité, et que je n'ai pas rencontré ce besoin encore, mais que ça serait handicapant.

• la très mauvaise lisibilité --> il est difficile, en lisant une grosse feuille de style xlst, de comprendre ce qu’elle fait, dans quel ordre sont faits les traitements, etc.

Mmmhh… dans les exemples que j'ai vu, je ne vois pas en quoi un code procédural serait plus lisible.

• le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.

Ça c'est clair que ça doit être rédhibitoire quand tu en as besoin.

• le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».

Encore une fois, je ne vois pas trop la différence. À moins que ça soit pour quelqu'un qui connaît mal XSLT, mais la critique peut alors valoir pour n'importe quel langage.

• la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)

J'ai effectivement un petit peu vécu ça, xsltproc que j'utilise pourrait être plus explicite sur certaines erreurs (comme quand tu appelles une template qui n'existe pas quand tu t'es trompé dans le nom).

• les perfs désastreuses

J'avoue ne pas avoir eu de problème avec ça, vu que mes fichiers sont de taille raisonnable.

Bref, personnellement, j’ai essayé, maintenant, j’évite autant que possible. À nombre de lignes égal, un programme est nettement plus lisible qu’une feuille xslt. Et xslt a tendance a être plus verbeux… :/

Oui, la verbosité n'aide vraiment pas. Mais ce qui me plaît vraiment et qu'on ne retrouve pas ailleurs, c'est la logique de parsing du langage : c'est hyper-bien adapté à du parcours d'arbre, et le matching est super pratique pour spécialiser certains cas. Ce genre de chose serait horrible à faire avec un autre langage. Tout ça se rapproche du fonctionnel, qui n'est pas facile à comprendre quand on est pas habitué, mais une fois que tu l'as saisi, ça simplifie tellement de choses…

En fait, il faudrait juste une version moins verbeuse. J'ai pensé à du YAML pour décrire les XSLT, je ne sais pas si ça pourrait le faire.

Merci pour ces remarques en tous cas, assez justes.

Dans le post originel, l'auteur comparait la popularité de XSLT à celle de COBOL

Ça tombe bien, il se trouve que j'ai déjà fait du COBOL : peut-être que niveau employabilité, ça le fait mieux (et encore, vu les usines à gaz Java qui touchent du XML, ça ne m'étonnerait pas que le XSLT soit populaire en entreprise bien que peu visible dans le libre, tout comme le COBOL), mais niveau « facilité » du langage, ça n'a rien à voir. Le XSLT est bien plus accessible et moderne (un langage plutôt déclaratif, quand même !) et, comme je le disais, apprenable assez facilement. Alors on peut mettre en face le fait que peu de monde le connaisse à priori, mais y mettre du Python et tous les risques associés que j'ai cité, ça ne me semble pas une très bonne idée.

Le code supprimé aurait très bien pu l'être dans sa forme XSLT, ça serait revenu au même, tout en gardant un langage fait pour ce travail. J'adore le Python, vraiment, mais pour certaines utilisations, il n'est vraiment pas adapté.

Après, tout ça c'est pour importer du OOXML, alors je pourrais m'en foutre aussi, mais bon, le XSLT m'a un peu appris le masochisme /o\

Les 4200 lignes de XLST ont été réécrites en 1300 lignes de Python - pour produire le même résultat avec une forte augmentation de la hackabilité.

Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.

J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :

http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.xsl?id=21977778168af134e7f72afcc07ff5062324a19d#n183

avec la version convertie en Python :

http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.py?id=6c4de449094048465b81abf93139bb5950fa12c9#n128

Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien…

En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :

http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=dd5dfc8e2a0fc3c0307c0a782ae563b79ba8a84e

Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document…

Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :

http://cgit.freedesktop.org/libreoffice/core/commit/?id=63cd667ccb35325a973cf4f98c5e1bf9db92b9b4

Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :

http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=2046fcd907fe8c0217c5cd43be8420859a0ad435

Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.

Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.

Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.

Je ne sais pas comment les prévenir, mais le site d'OpenUDC a l'air de s'être fait méchamment pirater…