[weboob] [weboob - Feature #403] ICapVideo may support paths

Nicolas Duhamel nicolas.duhamel2 at gmail.com
Fri Nov 19 12:48:58 CET 2010


 On Fri, 19 Nov 2010 09:30:31 +0100, Romain Bignon wrote:
> On 19/Nov - 08:52, Nicolas Duhamel wrote:
>> Sur ce point je suis d'accord, j'utilise pour le moment PathMap pour
>> permettre un
>> développement plus rapide, mais à l'usage je me rends compte qu'il
>> n'est pas tout à
>> fait adapter, donc pas la peine d'y jeter un œil il est voué à
>> disparaitre.
>
> Ok, cool !

 Je suis justement entrain de m'occuper de tools/path.py, je viens de me 
 rendre
 compte que os.path est dépendant du système (Win/linux) on est donc 
 obliger
 d'utiliser des fonctions de manipulation de path "maison" os 
 indépendant.
 Sauf si je me trompe.

 L'object PathMap doit servir à faciliter l'intégration des paths dans 
 les backends,
 en fournissant un objet de stockage et de manipulation des paths.



>
>> C'est en cours de développement, surement pour la fin de semaine
>> prochaine. Je détaillerais à
>> ce moment là.
>
> Très bien.d
>
>> Sur ce point on peut discuter dès maintenant.
>>
>> set_path() retourne deux iterateur (path, contenu) ce qui permet de
>> différencier facilement
>> les sous-répertoires du contenu.
>
> En fait, dans le cas où j'ai bien compris, je ne vois pas pourquoi 
> retourner
> deux itérateurs, alors qu'on pourrait n'en retourner un, et on
> pourrait soit :
> − Représenter les sous-répertoires avec un objet genre Directory 
> défini dans
> ICapPath, et un contenu serait un objet de type Video ou autre.
> L'application a
> juste à faire un isinstance pour chaque itération afin de savoir à ce 
> qu'il a
> affaire.
> — Avoir un objet Node qui représente soit un répertoire soit un
> contenu, avec un
> attribut de type, et qui dans le cas d'un contenu a un attribut
> 'content' avec
> l'objet Video.
>
 Le problème apparaît lorsque le nombre de sous-répertoires ou de 
 contenu ou les deux
 devient important.

 Dans le cas où un noeud contient plusieurs centaines de sous-dossiers 
 et du contenu,
 comment faire pour itérer que sur le contenu si les dossiers sont en 
 premier dans l'itération,
 et inversement.

>> Dans l'état actuel le backend part de la racine et remonte path par
>> path, le backend n'a pas
>> de "mémoire" du path courant il faut donc retourner les
>> sous-repertoires et le contenu au moment
>> où l'on change de path sinon cette information est perdu et le
>> changement de path ne sert à rien.
>
> Je ne saisis pas cette histoire de « remonter path par path ».

 Exemple:
 Avec alloshowtv
 J'ai pensé à un système de path virtuel (promis c'est pas compliqué), 
 lorsque l'on tente
 d'accéder à un répertoire depuis la racine le backend lance une 
 recherche avec les termes
 du path donné puis liste les resultats sous forme de repertoire:

 set_path("mad")
 retourne:
 Asuka e soshite mada minu koe
 Les Nomades du futur
 Mad men
 (...)

 puis lorsque l'on fait set_path("mad/Mad men") le backend effectue à 
 nouveau une recherche,
 vérifie si "Mad men" fait partis des résultats et si oui liste les 
 saisons.

 Ainsi de suite, à chaque fois que l'on tente d'accéder à un path le 
 backend part de
 la racine et remonte petit à petit jusqu'au répertoire final, du fait 
 que le backend
 ne possède pas de cache. De plus tant qu'il n'a pas parcourut les 
 répertoires précédant il
 est incapable de récupérer les saisons de Mad men.

 C'est sur ce point que le backend canalplus est particulier puisque 
 toutes les informations
 sur les catégories ce situent sur la même page, le backend est donc 
 capable quelque soit le path
 donné de le retourner en une seule action.

>
>> Maintenant si iter_path() retourne la même chose que set_path(), je
>> peux changer le nom de la fonction, et
>> il est vrai que cela semble plus logique puisque cette fonction
>> retourne des iterateurs.
>
> Oui.
>
>> Est-ce que set_path() ou iter_path() suffit ?!
>
> Pour ma part je pense que oui, le principal est qu'une fois qu'on a
> atteint un
> répertoire ayant du contenu, la méthode les retourne, et donc 
> l'objectif est
> atteint.
>
>> La suite la semaine prochaine !
>
> À ce sujet, Weboob 0.4 est prévue pour le mercredi premier décembre,
> soit dans
> un peu moins de deux semaines. Sachant que pour avoir quelque chose
> de stable il
> vaut mieux que ce soit bouclé d'ici la fin de la semaine prochaine,
> est-ce que
> tu penses que c'est envisageable pour 0.4 ou vaut mieux planifier ça
> dans 0.5 ?

 Tout dépend de mon emplois du temps de la semaine prochaine, je ne pas
 vraiment prévoir.

>
> Note qu'une fois que l'on aura défini une API, je pense que c'est 
> jouable
> de porter une partie des backends susceptibles de supporter cette 
> capability
> assez rapidement.
>
> Côté application, ce ne sera à mon avis pas bien compliqué, puisqu'il 
> se
> contente d'une commande cd qui appelle iter_path() et qui stock le
> résultat, ls
> affiche ces résultats, et play/info à modifier pour pouvoir prendre
> une valeur
> de résultat de iter_path().
>
> Romain




More information about the weboob mailing list