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 ;(
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Sat, 21 Feb 2009 18:57:39 +0000 (UTC),
espie@lain.home (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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
espie
In article , Paul Gaborit <Paul.Gaborit+ wrote:
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...
In article <wt9fxi7za7j.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit+news@mines-albi.fr> wrote:
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...
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
À (at) Sun, 22 Feb 2009 12:28:13 +0000 (UTC), (Marc Espie) écrivait (wrote):
In article , Paul Gaborit <Paul.Gaborit+ wrote:
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Sun, 22 Feb 2009 12:28:13 +0000 (UTC),
espie@lain.home (Marc Espie) écrivait (wrote):
In article <wt9fxi7za7j.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit+news@mines-albi.fr> wrote:
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 - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Sun, 22 Feb 2009 12:28:13 +0000 (UTC), (Marc Espie) écrivait (wrote):
In article , Paul Gaborit <Paul.Gaborit+ wrote:
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 - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
