WSGI, avec le recul, c’était vraiment une bonne idée.
Ce week-end, après avoir vu l’application Remote d’apple sur iPhone, je me suis dit que je voulais la même chose pour contrôler la lecture de films/musique sur ma tv via mon pc. Vu que mon téléphone actuel est un iphone, la voie la moins pénible est de faire une application web.
Autre prérequis, ce serait bien de se resservir du code fomenté pendant de nombreuses heures de mon temps libre : une espèce d’explorateur de système de fichiers dédié aux vidéos, et optimisé pour utilisation avec les touches haut+bas+return. L’extraction et la persistance des métadonnées se fait via un processus helper qu’on contacte via D-BUS (comme ça si le fichier vidéo provoque un plantage, l’application GTK reste vivante, et reste toujours aussi interactive que possible).
L’application (mediabrowser est son nom) est écrite en pygtk et utilise les bindings glib+D-BUS et gstreamer pour python. Pour recevoir des réponses asynchrones sans réécrire les bindings, il s’imposait donc pour l’application web (appelons la « remote » pour être original) de tourner dans un environnement qui utilise la mainloop glib.
Ca commence à faire des prérequis assez exotiques, mais il se trouve justement que Twisted permet d’installer comme boucle d’évènements un glib2 reactor. Parfait !
Me voilà donc en train d’expérimenter l’embarcation d’un serveur web dans mon application GTK2 et/ou l’écriture d’un programme externe qui réutilise tout le code de parcours de système de fichiers, d’extraction de métadonnées, etc ! Commencer un projet avec 75% du boulot déjà faits et directement réutilisables, c’est bien commencer 
Maintenant, phase d’expérimentation sur le framework http à embarquer. Les combinaisons testées sont :
- Web.py (out car besoin de glib.MainLoop)
- Twisted + web.py (sympa mais un peu limité)
- Twisted + tout à la main (heu, sympa mais pas vraiment le temps de réinventer tout ça)
- Twisted + dispatch via des resource.Resource Twisted (sympa mais ça a fait beaucoup de code à écrire à mon goût)
- Twisted + cherrypy (la version retenue et actuelle)
- Twisted + django (la version peut-être future si la version cherrypy devient difficile à maintenir avec plein de nouvelles fonctionnalités)
Et j’aurais pu en tester encore d’autres, dommage que le week-end ne dure pas 5 jours. Le tout sans modifier l’application conteneur (du tout). C’était bluffant à quel point le script Twistd (qui prend en argument un objet callable wsgi) n’a pas bougé … merci wsgi de m’avoir fait gagner de précieuses heures de temps libres, nan vraiment, merci.
On voit que les gens derrière tout ça n’aiment pas s’agiter dans le vide : N’importe quel framework/application web adhérant à la spec wsgi (et c’est vraiment facile) peut être embarqué dans n’importe quel conteneur wsgi (et Apache en fait partie). Certes c’est loin des paillettes et des jolies couleurs de certains écosystèmes à la mode, mais c’est ça qui rend plus facile la vie d’un développeur, pas de pouvoir écrire 5.days.from_now. Et wsgi n’est finalement qu’un exemple parmi d’autres de la manière dont fonctionne la communauté Python : si on doit gaspiller de l’énergie à faire plusieurs fois la même chose, autant que ce soit réutilisable.
Retour à « Remote ». Comme le contrôle à distance fonctionnouille à peu près, les quelques heures que j’ai à y consacrer cette semaine seront sûrement dédiées au transcodage à la volée en version mobile via gstreamer (un petit épisode de HIMYM en attendant le train ? (un hotspot wifi orange et un vpn devraient suffire)).
Promis, le code de tout ça sera bientôt dispo ! (oui, ça fait bien 2 ans que je promets ça pour Doohickey mais ne désesperons pas bande de mécréants !).
Related posts:
Post a Comment