Buf a écrit 449 commentaires

2 choses :

• le XML (ou JSON) proposé ici décrit les messages, pas forcément la forme que ça prendra sur le disque. On peut imaginer que le stockage sur disque se fasse dans un format différent, plus efficace.
• en XML, il n'y a pas que les documents complets, on a aussi les fragments XML. Ça évite d'avoir la contrainte d'une racine unique. On pourrait donc avoir un élément XML par entrée, sans tag qui entoure le tout. Ça garde une bonne partie des propriétés intéressantes du XML, et ça fait disparaitre d'un coup tous les problèmes que tu mentionnes.

Sinon, rien n’empêche tail (ou une autre commande) de reformater la sortie pour qu'elle soit comme tu veux (c'est pas ce qu'il y a de plus dur…).

Et c'est exactement ce genre d'outils que j'avais en tête, avant même de penser à une GUI.

Un truc qui permettent de filtrer les logs en ligne de commande, mais en donnant de vrais critères et pas via grep avec une regexp ad hoc, et qui sortirait les entrées dans un format lisible.

Le XML (ou JSON), c'est le format des messages. Ensuite, la façon dont c'est enregistré sur le disque importe peu. Si tu veux garder tes logs parsables à coup de grep/cut/awk, on peut sans doute imaginer un outil qui va aplatir la structure et virer les 3/4 des infos pour que ça rentre dans le format syslog et stocker ça dans des fichiers exactement tel que c'est fait aujourd'hui, et consulter ça avec des scripts qui cassent parce qu'on a une nouvelle version du logiciel qui introduit un champ supplémentaire dans ses logs.

Mais on peut aussi vouloir quelque chose de plus souple et plus pratique…

Je trouve un peu gros de rejeter la faute sur le code applicatif quand la base de données accepte sans erreur des données invalides. Je veux bien que ça soit un bug côté application, mais c'est en aucun cas une excuse pour que la base avale sans broncher derrière.

Garantir l'intégrité des données, c'est quand même un des rôles principaux d'une base de données.

Le but est de standardiser le contenu des logs et d'améliorer leur création par les applications qui les génèrent.

Pas seulement. Le gros intérêt du truc à mon avis, c'est pour les outils qui vont lire les logs.

En standardisant le format pour les évènements qui sont loggés, on facilite aussi grandement la création d'outils qui vont utiliser ces logs. Je pense par exemple à des systèmes d'alerte, de statistiques ou simplement un outil de consultation de log qui permette de trier et filtrer simplement tout ça, et qui présenterait les données sous une forme lisible.

CSV, c'est la fausse bonne idée par excellence. Le format a l'air simple à générer et à parser, mais en pratique, c'est une véritable horreur, parce que le format n'a pas de spécifications formelles (en particulier pour la gestion des caractères spéciaux). Un fichier CSV avec des entrées qui contiennent des retours à la ligne est très rarement bien géré, par exemple.

Le XML a le défaut d'être très verbeux, mais il a quand même l'immense avantage d'avoir une syntaxe stricte et bien définie.

Rien n'interdit d'avoir un type 'DATETIME' qui serait un alias vers TIMESTAMP. Mais effectivement, je suis d'accord, le nommage n'est pas très logique.

Par contre, ce qui est clairement impardonnable, c'est que MySQL réutilise un type définit par la norme et lui colle un comportement complètement délirant.

Ça ne change rien au fait que le standard existe, que certains font de vrais efforts pour s'y conformer au maximum (PostgreSQL, par exemple), alors que d'autre se torchent avec. MySQL est certainement pire que la plupart des bases de données proprio à ce niveau.

On peut aussi ajouter que le standard SQL n'a pas de type DATETIME, et utilise TIMESTAMP.

C'est pas encore vendredi, mais je me lance.

Quant à invoquer une arlésienne du nom de Standard SQL, je me gausse : aucune base de données n'implémente le moindre standard SQL totalement et sans particularités locales (sans compter que le standard est très incomplet sur certaines choses essentielles (…))

C'est marrant, on pourrait presque remplacer "SQL" par "HTML/CSS/Javascript" et MySQL par Internet Explorer, et dire pratiquement la même chose. Mais dans ce cas, tout le monde ici n'hésiterait pas à dire qu'IE, c'est de la daube.

Pourtant, la situation n'est pas bien différente : MySQL a bien des comportements bizarres et non-standards (documentés, certes, mais les trucs non standards d'IE sont eux aussi documentés), qui posent des problèmes de compatibilité.

Donc, je ne vois pas où est le problême.

Ben tu le dis toi-même :

Dans un script de démarrage, tu peux faire sereinement en background deux choses

Le problème, c'est tout le reste.

Mac OS X et iLife me conviennent très bien et je les utilise.

En même temps, on parle de PHP. S'il y avait la moindre cohérence dans la façon dont ils nomment les choses, ça se saurait.

Internet explorer avec les onglets à droite de la barre d'URL, c'est juste pour pas faire comme les autres ?

Tu parles de quels autres ? Firefox, qui met ses onglets au-dessus de la barre ? Chrome, qui les mets dans la barre de titre ? Ou Safari, qui les a sous la barre d'adresse ?

Et au fait, il y a une espace insécable devant ? et ! en français.

Histoire de finir d'exploser l'anus de drosophiles qui n'en demandaient pas tant : l'espace avant ? et !, c'est la convention en France.
En Suisse, on colle le signe de ponctuation à la lettre précédente (en fait, on utilise la convention typographique allemande)

Faut que ça soit géré au niveau du routeur, et qu'il configure dynamiquement le nat pour les ports supplémentaires utilisés par le FTP. C'est pas forcément le cas de tous les routeurs.

Sinon, on peut aussi utiliser un protocole moderne (genre SFTP, qui passe par SSH), et laisser tomber cette vieillerie de FTP.

Ça ne te protège quand même pas d'un keylogger qui enregistrerait ton mot de passe au moment où tu l'utilises.

Donc en fait, le libre, c'est bien, parce que ça permet de résoudre plus ou moins facilement un problème qu'on aurait pas eu du tout sur un OS proprio. C'est bien ça que tu es en train de dire ?

On a besoin d'argumenter un vendredi ? C'est nouveau ?

Le problème avec FTP, c'est qu'il y a 2 connexions ouvertes, une pour les commandes et une pour les données. La connexion de données pose problème au niveau des firewalls et des systèmes de translation d'adresse. Rien d'insurmontable, mais c'est du boulot en plus par rapport à HTTP qui nécessite juste de pouvoir ouvrir une connexion TCP entre le client et le serveur. Ça a aussi un cout niveau trafic réseau et ça ajoute une latence supplémentaire.

Ça suffit ou il faut que je continue en parlant de sécurité ?

Non, plus il y a de fichier, plus l’overhead de HTTP est grand.

On parle de quelques dizaines d'octets par fichier, c'est pas une grosse affaire. Et au passage, l'overhead du FTP est bien plus grand, parce que la connexion de données doit être réouverte pour chaque fichier (un handshake TCP par fichier, c'est considérable si on a beaucoup de petits fichiers)

Tu proposes quoi ? Tout faire passer au dessus de HTTP ? Tout faire passer au dessus de SSH (pas mieux que HTTP) ?

C'est quoi le problème de tout faire passer par HTTP ? Qu'il y ait 1 fichier ou plusieurs dizaines, HTTP me semble quand même être le protocole le plus adapté (en tout cas pour une utilisation sur Internet, sur un réseau interne, un partage NFS ou autre serait plus efficace)

FTP est un protocole obsolète qui mérite d'être enterré définitivement.

Même si je suis assez d'accord pour dire que le HTTP est aujourd'hui utilisé pour un peu tout et n'importe quoi, il ne faut pas tomber dans l'excès inverse non plus. Pour télécharger un fichier depuis Internet, HTTP est parfaitement adapté.

100 mo/s, c'est en lecture séquentielle si les données sont placées au bon endroit sur le disque. Avec des dizaines de lectures simultanées de données dispersées sur le disque, c'est beaucoup moins que ça.

Vu mon avatar, je me sens obligé de répondre ici.

Et en plus, un occidental non francophone est autant largué sur un clavier français qu'un frqn;qis sur un clqvier qutre aue frqn;qis ;-)

Un francophone non-français peut aussi être complètement largué sur un clavier azerty (en Suisse, on a du qwertz, basé sur la disposition allemande, et nettement plus pratique que cette daube d'azerty)

Le concept est peut-être intéressant (ou peut-être pas, j'ai pas regardé en détail), mais ça n'a rien à voir avec ce qui est discuté ici.