Il y a quelques mois de ça, je découvre Smarty, un moteur de template pour PHP. À première vue, ce concept de template fait très envie en mettant fin au morceaux de html dans tous les sens au milieu du code PHP. On découpe mieux, c'est plus beau, plus propre, plus professionnel, etc.

Mais finalement… ne pourrait-on pas faire la même chose sans s'encombrer d'un outil pareil ? Comme on me l'a justement fait remarquer il y a quelques temps : « bué ça sert à rien, PHP c'est déjà un moteur de templates ». C'est vrai ça, pourquoi ne pas simplement faire un dossier tpl dans lequel on irait y mettre des fichiers tels que head.php, foot.php, form_inscr.php, etc. puis les intégrer à coup de include() dans le core ?

Outre le fait que des moteurs de templates semblent facultatifs avec ce genre de manipulation, on se rend compte que les développeurs de moteur de templates fournissent un système de conditions et de boucles en tout genre. On retrouve donc des if/while dans les templates, avec une énième syntaxe… c'est le monde à l'envers non ? Autant directement faire du bouclage dans la template en .php comme vu juste au dessus, qui sera certainement bien plus efficace.

Pour finir, il ne faut pas oublier qu'intégrer un outil comme Smarty demande une maintenance supplémentaire pour le développeur, et peut potentiellement rajouter des problèmes de sécurité. Et si un jour le moteur n'est plus maintenu pour une raison X ou Y et que le PHP ne supporte plus des fonctions deprecated effectuées par le moteur de template, on fait quoi ? On refait tout le site ? On maintient le moteur nous même en plus du site ?

Vu le niveau de complexité de petits outils comme Smarty je dois oublier quelque chose d'important dans l'histoire, mais je ne vois pas quoi. Et s'il y a quelques petits avantages pratiques (ce dont je suis presque certain), est-ce qu'ils valent vraiment le coup par rapport à ce que l'on y perd ?

Attention, je ne traite ici des moteurs de template que dans le cas du PHP.

Tiens, pourquoi je ne poste des journaux que le vendredi ?…

> Lire le journal (45 commentaires, moyenne: 3,3).

Cher journal,

Aujourd'hui je me décide à enfin poster sur mon retour d'expérience du protocole MSN (ou plutôt Live Messenger pour faire tendance).

Déjà je suis étonné de voir que personne n'a parlé de la version 2 de aMSN. Alors avant toute chose, je vous conseille d'aller jeter un coup d'œil ici : http://www.amsn-project.net/forums/viewtopic.php?t=5299

Pour les feignants, ça dit en gros que les dev de emesene rejoignent (en partie) la team aMSN pour faire un nouveau client from scratch en Python, utilisant la librairie pymsn et avec la possibilité de coller n'importe quel front-end par dessus. On a d'ailleurs vu germer en plus de f-e par défaut EFL (lib enlightment) le f-e GTK, Qt, et même web (en Ajax).

Avant de vous précipiter dessus comme des pucelles effarouchées ou d'aller harceler les dev sur leur chan IRC, il faut savoir qu'il n'y a pas de version pleinement utilisable encore. Le dépôt est en revanche accessible sur github si vous voulez contribuer (HOWTO Contribute to aMSN2).

Pendant cette période d'émergence du client, je me suis formé doucement à cette librairie pymsn en codant mon propre petit client. J'ai donc un client à peu près utilisable qui fait des choses basiques, et surtout qui peut servir à d'autres qui aurait besoin d'une base afin de voir comment fonctionne un peu la librairie (la « doc' » ne suffit pas vraiment). Il existe aussi un autre client nommé elloquence (qui ne marche plus bien à cause des évolutions de la lib si je me souviens bien) qui m'a bien aidé pour comprendre comment marche pas mal de choses.

Je suis malheureusement actuellement confronté à des problèmes avec la librairie (des implémentations manquantes, des bugs, etc.). C'est la seule librairie qui va être maintenue dans le futur, mais actuellement elle ne l'est pas du tout. Les anciens dev recherchent un nouveau mainteneur. Il n'est vraiment pas évident actuellement de proposer des patch ou d'avoir une lib à jour. Résultat, tous les clients ont un fork de pymsn dans leur dossier, et ce n'est vraiment pas terrible pour centraliser les patchs ou avoir une lib solide.

Actuellement, les développeurs de aMSN2 n'ont pas le temps de s'en occuper (ils sont plus préoccupés par leur nouveau proof-concept, et la lib leur suffit bien pour l'instant). Résultat ça n'avance pas, et ça reste de la grosse bidouille du coté du client pour adapter le comportement de la librairie.

Il faut bien comprendre que le protocole MSN est vraiment quelque chose de… « compliqué » si je puis dire. Et par dessus tout, la librairie pymsn n'est pas simple d'accès pour un codeur qui a les bases en python. J'ai un manque clair de compétences (et de temps comme tout le monde) pour m'y plonger plus profondément que je ne l'ai fait actuellement.

Je vais terminer avec un petit retour d'expérience. Je travaille actuellement sur un meilleur support des avatars/nickname du profil courant ; je cherche à ce qu'il soient automatiquement récupérés sur le serveur distant plutôt que sauvegardé en local. En fait, quand on spécifie que l'on change son avatar (quand la session est ouverte), c'est un signal qui est envoyé à tous les contacts de la liste. Et si on veut pouvoir le récupérer à la prochaine session, il faut aussi l'uploader sur un serveur Microsoft (système de ContentRoaming). Ce qui en gros signifie que quand vous changez d'avatar, vous envoyez un signal (« Hey les amis mon avatar il a changé !!!! ») et là, vos 90 contacts vont vous demander votre avatar et vous allez l'envoyer à chacun d'entre eux (Ça y'est, vos pics de bande passante s'expliquent ?…). Il ne faut pas non plus oublier de l'uploader sur le serveur Microsoft pour le prochain login. Bref, il faut reconnaître que c'est quand même beaucoup moins du minitel 2.0 que jabber où les avatars sont stockés sur le serveur (Ah non merde, c'est aussi le cas avec MSN, et en plus le serveur est centralisé, j'aurais mieux fait de me taire). Quoi qu'il en soit, cette procédure, avec pymsn, n'est vraiment pas des plus simple. Il n'existe aucune méthode qui fait tout ça simplement, et c'est vraiment la galère. Alors plutôt que d'implémenter des hacks supplémentaires dans le client, je préférerais travailler sur le lib, sur un système comme github ou chacun peut contribuer facilement, parceque actuellement c'est vraiment mort, et proposer un patch n'est pas accessible du tout.

Tout ça pour dire au final qu'il y a un besoin de développeur^Wmainteneur pour pymsn, car sans ça, rien n'avance. Donc si quelques personnes se sentent intéressés, ce serait vraiment super.

Je sais bien que c'est un protocole fermé, destiné à mourir, qui entretient le géant capitaliste et tout ce que vous voulez. Mais en même temps, je pense que c'est une expérience très enrichissante de travailler sur quelque chose d'obscure et proprio (en plus on peut cracher dessus après, et ça, ça n'a pas de prix). D'autre part, ça fait des années qu'on attend le support de la vidéo dans jabber (non je ne peux pas vraiment participer c'est pas encore « standardisé ») alors que la video est intégrée dans le protocole de MSN depuis longtemps. Alors certes, c'est surement un bordel sans nom, mais en attendant c'est quand même intéressant de pouvoir proposer un support vidéo qui permette d'échanger avec un maximum de monde.

Voilà, c'est fini. Désolé si ce billet est un peu décousu, j'ai voulu dire beaucoup de choses mais j'ai l'impression d'avoir brassé beaucoup d'air pour pas grand chose… Je ferais mieux au prochain journal (ou pas).

PS : qu'est-ce que ça change de sélectionner « journal de {première,seconde} page ? »

> Lire le journal (113 commentaires, moyenne: 3,2).