J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 4.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.