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 ;(
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Paul Gaborit
Le #18730401
À (at) Sat, 21 Feb 2009 18:57:39 +0000 (UTC),
(Marc Espie) écrivait (wrote):
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.



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.

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.



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 ! ;-)

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 ;(



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 -
espie
Le #18733131
In article Paul Gaborit
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.





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 ! ;-)



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...
Paul Gaborit
Le #18733221
À (at) Sun, 22 Feb 2009 12:28:13 +0000 (UTC),
(Marc Espie) écrivait (wrote):
In article Paul Gaborit
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.





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 ! ;-)



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...



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).

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...



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 -
Publicité
Poster une réponse
Anonyme