• [^] # Re: Le but est de standardiser le contenu des logs

    Posté par (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 3.

    multiplier les formats n'est pas forcément un avantage. Il vaut mieux, selon les contraintes, utiliser quelque chose de mal adapté mais assez bien maîtrisé qu'un format spécifique.

    Ca dépend vraiment des cas.

    Un projet qui aurait par exemple sa conf en yaml, qui sérialiserait un certain nombre de données en json (stockées par exemple en base, renvoyées au client web, etc), voir même qui boufferait du json directement depuis postgresql, et qui aurait aussi de l'xml à certains endroit, juste pour pouvoir utiliser du xsl et faire des transformations intéressantes ne me choque pas plus que ça.
    La critique était valable, il me semble, il y a quelque temps, lorsque les libs n'étaient pas là.
    Mais si on a un parseur/lib correct pour les différents format alors il n'y a aucun soucis, d'ailleurs à ce moment le format devient quasiment transparent. Par exemple, dernièrement j'ai utilisé gson pour sérialiser différentes informations, ben y'a pas à chier c'était bien plus rapide que de le faire en xml.

    D'ailleurs, json a un avantage certain sur xml : plus personne ne fait d'ajax, quasiment tout le monde fait de l'ajaj (oué on pourrait aussi juste dire aj), les données sont de plus en plus envoyées / reçues en json. L'XML était peut-être une bonne idée, mais lorsqu'on voit le coup d'un parse xml / xsl côté client, on oublie vite.
    Et donc si on dialogue en json, on a tout intérêt à stocker / cacher / etc les données en json pour pouvoir dialoguer à moindre coût.