Ce n'est pas pour te contrer par plaisir mais ce que tu exposes n'est que détails pour moi. Pourquoi? D'abord parce que, même si c'est un foutoir sans nom (je peux le concevoir), l'utilité des journaux (par rapport à ceux de Windows) est incontestable. Même si c'est un foutoir innommable, les informations qu'il contient sont précieuses et pertinentes, elles aident au dépannage, faut pas perdre ça de vue.
Le jeu de caractères? le journal binaire doit aussi en utiliser un, ça ne règle pas la question, comme je l'ai exposé. La date n'est pas dans un format stable et précis ou exploitable? Ok, pourquoi pas définir une API, dans ce cas? Les standards aussi, ça sert à ça.
Il n'est pas plus facile de «normer» du binaire que du texte. Tous tes arguments (pour le binaire) sont recevables mais s'appliquent aussi au texte. Le texte n'empêche pas sa normalisation. (Sinon quid de XML, des fichiers INI, qui sont déjà des exemples de formats texte normés?) Tout ce que le journal demande pour répondre à ces exigences est une normalisation, comme tu l'as dit. Fallait-il vraiment passer au binaire pour ça?
Il existe de nombreux formats de date, par exemple, dont ISO. Un format "YYYY-MM-DD hh:mm:ss[.ms]" n'aurait-il pas répondu à cette exigence? Et s'il faut faire des recherches plus sophistiquées, par exemple filtrer par intervalle de temps, on peut quand même y arriver avec sed ou gawk, même si c'est plus un casse-tête qu'autre chose. Mais c'est déjà faisable avec du texte, pas besoin de passer au binaire pour ça. Avec un fichier texte bien structuré, bien formaté, pas besoin de binaire. D'autant plus qu'il existe des versions de syslog qui permettent de stocker des lignes de journal dans une base de données, pour «des trucs très précis». Je ne me souviens plus si la date fait partie des arguments par contre. Mais quand bien même, faire une API pour ça me paraît plus sage que ce passage brutal et méchant au binaire.
[^] # Re: Journal en fichier binaire vs fichier plat
Posté par FantastIX . En réponse à la dépêche Documentation du format du Journal. Évalué à 3.
Ce n'est pas pour te contrer par plaisir mais ce que tu exposes n'est que détails pour moi. Pourquoi? D'abord parce que, même si c'est un foutoir sans nom (je peux le concevoir), l'utilité des journaux (par rapport à ceux de Windows) est incontestable. Même si c'est un foutoir innommable, les informations qu'il contient sont précieuses et pertinentes, elles aident au dépannage, faut pas perdre ça de vue.
Le jeu de caractères? le journal binaire doit aussi en utiliser un, ça ne règle pas la question, comme je l'ai exposé. La date n'est pas dans un format stable et précis ou exploitable? Ok, pourquoi pas définir une API, dans ce cas? Les standards aussi, ça sert à ça.
Il n'est pas plus facile de «normer» du binaire que du texte. Tous tes arguments (pour le binaire) sont recevables mais s'appliquent aussi au texte. Le texte n'empêche pas sa normalisation. (Sinon quid de XML, des fichiers INI, qui sont déjà des exemples de formats texte normés?) Tout ce que le journal demande pour répondre à ces exigences est une normalisation, comme tu l'as dit. Fallait-il vraiment passer au binaire pour ça?
Il existe de nombreux formats de date, par exemple, dont ISO. Un format "YYYY-MM-DD hh:mm:ss[.ms]" n'aurait-il pas répondu à cette exigence? Et s'il faut faire des recherches plus sophistiquées, par exemple filtrer par intervalle de temps, on peut quand même y arriver avec sed ou gawk, même si c'est plus un casse-tête qu'autre chose. Mais c'est déjà faisable avec du texte, pas besoin de passer au binaire pour ça. Avec un fichier texte bien structuré, bien formaté, pas besoin de binaire. D'autant plus qu'il existe des versions de syslog qui permettent de stocker des lignes de journal dans une base de données, pour «des trucs très précis». Je ne me souviens plus si la date fait partie des arguments par contre. Mais quand bien même, faire une API pour ça me paraît plus sage que ce passage brutal et méchant au binaire.