j'ai posé un tag sur la version en cours de développement : 1.5a1 ; histoire
de dire qu'on avance, mais en alpha (lire "instable")...
Nouveauté : l'introduction d'un mécanisme permettant de loger ce que fait
spip dans un fichier data/spip.log (qui tourne sur 3 fichiers de 10ko maxi
chacun). Le format des logs est relativement standard :
Oct 24 01:03:15 spip www-data[605]: envoi mail nouveautes
(date et heure) spip uid[pid]: message
Dans inc_version.php3, l'utilisateur peut activer $debug=true;, ce qui fera
"journaliser" (il paraît qu'on dit comme ça) plus d'événements (pour
l'instant, aucun...)
Le code à installer est simplement :
spip_log("message"); // message à journaliser systématiquement
spip_debug("message"); // msg à journaliser si $debug=true;
Nouveauté : l'introduction d'un mécanisme permettant de loger ce que fait
spip dans un fichier data/spip.log (qui tourne sur 3 fichiers de 10ko maxi
chacun). Le format des logs est relativement standard :
Oct 24 01:03:15 spip www-data[605]: envoi mail nouveautes
(date et heure) spip uid[pid]: message
PS: dans le format de log, je me demande s'il ne faut pas mettre (1) l'IP
client et (2) l'URI appelante, ou un hash de cette URI, ou le nom du fichier
cache ; ça pourrait s'avérer utile, non ?
Par ailleurs, dans la fonction spip_log ne crains-tu pas des écrasements
possibles (par ex. que deux enregistrements soient demandés en même
temps et soient finalement "mélangés" dans le spip.log) ? Sur Unix c'est
certainement possible (problème classique de logger). Dans ce cas, il
faudrait passer soit par un système de lockfile (bof) soit par une table
MySQL pour logguer (encore plus bof) soit s'en foutre (un peu bof).
Par ailleurs, dans la fonction spip_log ne crains-tu pas des écrasements
possibles
Pas trop ; je crains surtout les temps d'attente... mais de toutes façons on
fait ça avec la création de inc_meta_cache, sans souci jusqu'à maintenant.
On avait des problèmes autrefois, quand on ouvrait le fichier, puis qu'on
écrivait dedans au fur et à mesure des calculs, avant de fnalement le
fermer. Maintenant on calcule, puis on ouvre, écrit tout et ferme dans la
foulée, et l'erreur qui apparaissait parfois ne m'a plus jamais été
signalée.
soit s'en foutre (un peu bof).
Me paraît une bonne solution. En gros, mon idée est la suivante : spip_log()
ne doit pas logguer chaque événement mais chaque événement *important*, donc
il n'y aura pas trop de risques de concurrence. Par contre, spip_debug()
peut agir assez violemment, mais activer $debug = true; sur un site à fort
trafic, c'est qu'on sait ce qu'on veut
PS: dans le format de log, je me demande s'il ne faut pas mettre (1) l'IP
client et (2) l'URI appelante, ou un hash de cette URI, ou le nom du fichier
cache ; ça pourrait s'avérer utile, non ?
Je mets l'IP, mais pas l'URI (trop longue). Pour l'URI, il faudra passer en
mode debug. Ca va ?