[weboob] [Weboob] Pourquoi personne ne contribura à weboob

John Obbele john.obbele at gmail.com
Fri Aug 20 17:17:37 CEST 2010


Désolé pour le titre racoleur :)

Donc, suite à ma proposition de patch pour une interface en ligne
de commande alternative, Romain m'a proposé de critiquer ce qui
ne va pas dans dans votre documentation.

Voici ce que je peux en dire :

                      ---------------------

(mise en garde: je ne suis pas un développeur professionnel et je n'ai
jamais compris en quoi la programmation orientée objet apportait plus
d'avantages que d'inconvénients …)

I. À propos des frontends / applications
========================================

Il n'y a pas de how-to ou de guide d'utilisateur pour les
tartuffes.  Genre, dans le champ 'usage' de '--help', une manpage
ou sur le wiki[0], il faudrait ajouter ajouter 3 lignes disant:

-1) on gère les informations de la RATP

-2) c'est très utile, la preuve je m'en sers tous les jours en faisant
	bash $ travel departures "Gare du Nord" "Gare de Lyon"

-3) Profits !

Pas la peine de fournir une application super évoluée, mais au minimum 1
ou 2 objectifs et un cas d'utilisation typique.

[0]: https://symlink.me/projects/weboob/wiki/Transilien

II. À propos du développement
=============================

A. Mutualisation des ressources
-------------------------------

Comme je le comprends, une des idées majeures de Weboob est de mettre en
commun plusieurs web-scrappers et, dans la foulée, proposer une API
unifiée d'accès aux diverses fonctionnalités (les ICapabilities).

C'est surement utile, le hic, c'est que nainporte quel barbu dans son
garage aboutira à la conclusion du SVG en pièce jointe : mais pourquoi
est-ce que je devrais me farcir l'usage d'une dizaine de classes
d'abstraction juste pour récupérer 3 lignes de texte sur le net ???

L'intérêt de ces abstractions pour les backends a l'air d'avoir
déjà été partiellement traité[1], mais pas pour les frontends[2].

[1]: http://weboob.org/Backends_hacking
[2]: http://weboob.org/Application_hacking

Si ça peut vous aider, le SVG en pièce jointe mentionne les
fonctions utilisées lors de l'écriture du frontend REPL. En gros
je n'ai eu besoin que de weboob.do(action, *args) et
weboob.load/unload_backends(). Par contre je n'ai pas encore
fourré mon nez dans les configurations ou votre usage d'optparse
(ou de ce qui le remplacera), je ne dirais donc rien à leur
sujet.

B. Je n'aime pas les objets
---------------------------

Et il y a une chose que je ne comprends pas : pourquoi avoir mis
BaseApplication et ConsoleApplication dans weboob.tools et pas dans
weboob.core ou weboob.applications{.share} ?

Même raisonnement pour weboob.tools.{browser,parsers}.

Je suis trop fainéant pour faire du saute mouton de Videoob à
Weboob en passant par ConsoleApplication et BaseApplication, le
tout dans 3 dossiers / modules différents, juste pour comprendre
à quoi sert la fonction "do(action, …)" (que j'aurais nommé
"broadcast" ou "dispatcher", mais les goûts et les couleurs hein
^^).

C. Différence entre "frontends" et "applications"
-------------------------------------------------

Embroglio numéro 3, dans la même optique: c'est quoi la différence entre
"frontends" et "applications" ?  Pourquoi deux dossiers différents ?

III. Programmez en Haskell, pas en C
====================================

(Parce qu'on est vendredi.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weboob_documentation.svg
Type: image/svg+xml
Size: 209182 bytes
Desc: not available
URL: <http://lists.symlink.me/pipermail/weboob/attachments/20100820/66794d28/attachment-0001.svg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.symlink.me/pipermail/weboob/attachments/20100820/66794d28/attachment-0001.pgp>


More information about the weboob mailing list