Salut,
Toujours penché sur les API de Locust, je suis en train de réfléchir à
Locust::Input, qui est l'objet de base de gestion des inputs.
Plus j'y pense et plus je me dis que c'est intéressant que ce soit
un IO::Handle :
- on peut utiliser toutes les fonctions classiques dessus (le passer
à un objet IO::Select, récupérer la prochaine ligne, etc.)
- récuperer une de log ne préjuge pas du handle sous-jacent (fichier,
pipe, socket (avec notre objet comme server ou comme client, je
pense qu'on peut même controler ça)
Du coup, il est peut-être inutile de faire une hiérarchie compliquée
de Locust::Input::File|Socket|Server, etc. pour chaque cas particulier.
On peut se contenter de faire :
my $input = Locust::Input->new(
$handle, # IO:Handle obtenu par ailleurs
match => qr/^(\d{8} \d\d:\d\d:\d\d) (\w+) (\w+) (\w+) (\S+) (.*)$/,
fields => [ qw( date host facility level program message ) ],
datefmt => "%Y%m%d %H:%M:%S",
);
et d'avoir des options pour gérer les cas connus :
file => '/var/log/syslog', # fichier
connect => 'host:999', # lit sur le port 999 de host
# et si on veut se transformer en serveur syslog...
listen_tcp => ':999', # ecoute sur le port 999
listen_udp => '127.0.0.1:999', # ecoute sur le port 999
Les objets IO::Handle sont un petit peu plus difficiles à manipuler
(ce sont dss globs), mais je pense que ça vaut le coup.
Je vais essayer de commiter un Locust::Input qui marche d'ici ce soir.
--
Philippe "BooK" Bruhat
The truly stupid always find a way to create disaster.
(Moral from Groo #10 (Image))
