Je me rappelle que Keith Packard annonçant après plusieurs mois de boulot qu'on ne pouvait pas améliorer la latence et le traffic d'X-Windows. Que tout ce que son équipe avait réussi en optimisant ici ou la le code était du même ordre de grandeur que la compression gzip réalisée par ssh avec l'opion -C. Bref, il concluait que le protocole X n'avait pas été conçu pour les faibles bandes passantes et qu'il n'y avait pas grand chose à y faire...
Puis, peu de temps après, No-Machine sortait NX qui permettait de faire du X sur des liaisons ADSL ! Personne n'y a cru mais on avait tous tords... NX marche super bien.
Bref, tout cela pour dire que bouffer du CPU pour compresser par gzip les fichiers XML tout cela parce qu'on pense que le XML ASCII, c'est génial et qu'on fera pas mieux, comme toi, je ne suis pas d'accord.
Il est bien plus rentable de passer des tableaux de nombres réels via HDF5 ou NetCDF qu'en XML ou il faut les écrire avec la quinzième décimale et ou cela prend un place folle et n'est pas du tout optimale pour le transfert.
Contrairement à NetCDF très orienté tableau, le format HDF5 permet de stocker une structure arborescente. C'est pour cela que j'ai parlé de lui. Ce serait intéressant d'avoir sur ce genre d'outil un portage de l'API XML, rien que pour voir.
[^] # Re: WYDSIWYGBYMDIFTSIIN
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Un éditeur XML Wysiwyg passe au libre. Évalué à 4.
Je me rappelle que Keith Packard annonçant après plusieurs mois de boulot qu'on ne pouvait pas améliorer la latence et le traffic d'X-Windows. Que tout ce que son équipe avait réussi en optimisant ici ou la le code était du même ordre de grandeur que la compression gzip réalisée par ssh avec l'opion -C. Bref, il concluait que le protocole X n'avait pas été conçu pour les faibles bandes passantes et qu'il n'y avait pas grand chose à y faire...
Puis, peu de temps après, No-Machine sortait NX qui permettait de faire du X sur des liaisons ADSL ! Personne n'y a cru mais on avait tous tords... NX marche super bien.
Bref, tout cela pour dire que bouffer du CPU pour compresser par gzip les fichiers XML tout cela parce qu'on pense que le XML ASCII, c'est génial et qu'on fera pas mieux, comme toi, je ne suis pas d'accord.
Il est bien plus rentable de passer des tableaux de nombres réels via HDF5 ou NetCDF qu'en XML ou il faut les écrire avec la quinzième décimale et ou cela prend un place folle et n'est pas du tout optimale pour le transfert.
Contrairement à NetCDF très orienté tableau, le format HDF5 permet de stocker une structure arborescente. C'est pour cela que j'ai parlé de lui. Ce serait intéressant d'avoir sur ce genre d'outil un portage de l'API XML, rien que pour voir.