libwww, HTTP::Daemon
Le
espie
est-ce que quelqu'un connait une adresse email "active" pour le developpement
de celle-ci ?
J'ai essaye de faire deux/trois trucs avec HTTP::Daemon, pour constater que
c'etait "juste" une classe exemple relativement limitee et mal foutue.
En gros les quelques methodes qu'elle embarque sont tres monolithiques, ce
qui fait qu'on ne peut pas en deriver pour en faire quelque chose
d'intelligent sans devoir reprendre enormement de code.
Pour vous faire une idee, j'essayais d'interfacer HTTP::Daemon et
WWW::Mechanize pour pondre une sorte de "proxy", avec utilisation de
HTML::TreeBuilder au milieu pour alterer le contenu avant de le rebalancer.
Je me suis retrouve a avoir plein de soucis avec HTTP::Request (en particulier,
pas evident de prendre du POST et de balancer dans Mechanize) et avec
HTTP::Daemon lui-meme (qui n'a l'air guere prevu que pour faire du
send_file, et qui n'a pas de methodes et de sous-classes propres pour
manipuler du HTTP::Headers correctement).
Bref avant de reinventer la roue, j'ai essaye d'envoyer un mail a l'adresse
listee dans libwww sans succes depuis une semaine ;(
de celle-ci ?
J'ai essaye de faire deux/trois trucs avec HTTP::Daemon, pour constater que
c'etait "juste" une classe exemple relativement limitee et mal foutue.
En gros les quelques methodes qu'elle embarque sont tres monolithiques, ce
qui fait qu'on ne peut pas en deriver pour en faire quelque chose
d'intelligent sans devoir reprendre enormement de code.
Pour vous faire une idee, j'essayais d'interfacer HTTP::Daemon et
WWW::Mechanize pour pondre une sorte de "proxy", avec utilisation de
HTML::TreeBuilder au milieu pour alterer le contenu avant de le rebalancer.
Je me suis retrouve a avoir plein de soucis avec HTTP::Request (en particulier,
pas evident de prendre du POST et de balancer dans Mechanize) et avec
HTTP::Daemon lui-meme (qui n'a l'air guere prevu que pour faire du
send_file, et qui n'a pas de methodes et de sous-classes propres pour
manipuler du HTTP::Headers correctement).
Bref avant de reinventer la roue, j'ai essaye d'envoyer un mail a l'adresse
listee dans libwww sans succes depuis une semaine ;(
Poser une question
(Marc Espie) écrivait (wrote):
Je ne suis pas sûr qu'elle (HTTP::Daemon) soit réellement en
développement. Elle a le mérite d'exister pour des usages simples.
Ne serait-ce pas plutôt HTTP::Proxy qui serait le module le plus
indiqué ? Et là, en cas de soucis, l'auteur a du répondant,
c'est sûr ! ;-)
Laquelle ? Si c'est celle de Gisle Aas, quand on voit le nombre de
modules auxquelles il participe, cela ne m'étonne pas qu'il ne soit
pas toujours très réactif !
--
Paul Gaborit - Perl en français -
Tiens, je ne connaissais pas. C'est quand meme tout pourri comme approche.
Il y a des gens qui ont des progres a faire en design oriente objet...
A la base, tu as des jolies classes qui pourraient etre presqu'utilisables.
La bonne facon de faire, ca serait qu'il soit simple d'heriter de ces
classes, de facon a ne specialiser que le comportement qui t'interesse.
A la place, tu as un comportement "opaque" avec une interface a base de filtres
extremement generale (trop) et compliquee par rapport a la plupart des
applications que tu pourrais vouloir deployer....
Ce genre d'application, ca devrait etre quasiment un cas d'ecole de
l'utilisation du design pattern Template Method...
(Marc Espie) écrivait (wrote):
Je t'avouerai franchement que je n'ai jamais utilisé HTTP::Proxy (sauf
pour faire un tout petit programme d'analyse du protocole HTTP pour
mes étudiants à l'époque où Firebug n'existait pas).
Mais si l'approche ne te plait pas, n'hésite pas à en parler à Book
(ou P.Bruhat - l'auteur), je suis sûr qu'il sera attentif (ou au moins
de bon conseil).
Tu as certainement raison.
Il y a aussi un souci plus général qui est qu'il n'y a pas un modèle
Perl pour les classes et l'héritage : il y en a plusieurs ! Ça n'aide
pas obligatoirement à faire propre surtout lorsqu'on empile différents
modèles (je ne sais pas si c'est le cas ici).
--
Paul Gaborit - Perl en français -