Frénésie et Web
10/21/2005 02:22:00 AM
Ces temps-ci, je suis un geek à l'affût.
J'ai beaucoup codé pour la thèse, débugué une lib qui nous servira à faire des outils de preuve plus ou moins assistants/assistés. Voyant que je tenais le bon bout j'ai mis le paquet, toute la journée. Pas vu le soleil, stressé à mort, pas une vie.
D'autre part, j'ai du allumer mon serveur web l'autre jour pour un pote, et la mise à jour gentoo d'apache me contraignait à bouger ma conf, lire l'immonde apache.conf. Dans un coin de ma tête j'avais noté l'émergence du projet
J'ai lu, blabla, lighttpd opte pour le FastCGI pour php. Ca veut dire qu'il lance quelques processus interpréteurs php, qui vont recevoir des requêtes d'exécution de tel ou tel script quand les utilisateurs veulent. Ce qui est chouette c'est que tes process interpretes peuvent être lancés en tant que nobody, sur une machine distante, etc. Mais à la limite je m'en tamponne.
Le truc sexy, c'est que FastCGI ça existe sur tous les serveurs, c'est un protocole simple et ouvert, et il a été implémenté dans de nombreux langages. Je remonte donc une vieille lubie qui me parait désormais sérieuse: écrire mon service web en Caml. J'avais à l'époque écrit une série de scripts CGI en Perl qui se connectaient à liquidsoap en telnet pour passer une requete utilisateur, sauter un morceau, demander la liste des morceaux précédents/suivants. Une des frustrations avec ce genre de système c'est que si 3 utilisateurs demandent la liste des fichiers ça va créer trois connections, recevoir la liste, l'afficher, fermer boutique. L'avantage de FastCGI par rapport à CGI c'est que le serveur de requêtes est persistant. Donc on peut avoir son process qui périodiquement met à jour les informations qui s'y prêtent et les délivre à tout allure à la demande de la myriade d'utilisateurs. Du coup je m'installe OCamlNet et cgi_template, et codouille codouille, dans la foulée je dépile même un peu ma TODO list liquidsoap..
En tout cas avec ces conneries je suis encore tout éveillé, mais va sérieusement falloir que je me mette en veille.
J'ai beaucoup codé pour la thèse, débugué une lib qui nous servira à faire des outils de preuve plus ou moins assistants/assistés. Voyant que je tenais le bon bout j'ai mis le paquet, toute la journée. Pas vu le soleil, stressé à mort, pas une vie.
D'autre part, j'ai du allumer mon serveur web l'autre jour pour un pote, et la mise à jour gentoo d'apache me contraignait à bouger ma conf, lire l'immonde apache.conf. Dans un coin de ma tête j'avais noté l'émergence du projet
lighttpd, un serveur simple et rapide. Pour la rapidité je suis pas expert, pour les fonctionnalités non plus, pour la sécurité pas plus. Mais il a l'air d'avoir sa communauté bien avec lui, et on lit pas d'écho négatif sur le web. En tout cas je peux vous le dire, je l'ai vu de mes yeux, pour la simplicité c'est un délice. La conf est au plus simple. Si tu veux plus de fonctionnalité tu ajoutes des plugins, et j'ai pu faire des choses chouettes.J'ai lu, blabla, lighttpd opte pour le FastCGI pour php. Ca veut dire qu'il lance quelques processus interpréteurs php, qui vont recevoir des requêtes d'exécution de tel ou tel script quand les utilisateurs veulent. Ce qui est chouette c'est que tes process interpretes peuvent être lancés en tant que nobody, sur une machine distante, etc. Mais à la limite je m'en tamponne.
Le truc sexy, c'est que FastCGI ça existe sur tous les serveurs, c'est un protocole simple et ouvert, et il a été implémenté dans de nombreux langages. Je remonte donc une vieille lubie qui me parait désormais sérieuse: écrire mon service web en Caml. J'avais à l'époque écrit une série de scripts CGI en Perl qui se connectaient à liquidsoap en telnet pour passer une requete utilisateur, sauter un morceau, demander la liste des morceaux précédents/suivants. Une des frustrations avec ce genre de système c'est que si 3 utilisateurs demandent la liste des fichiers ça va créer trois connections, recevoir la liste, l'afficher, fermer boutique. L'avantage de FastCGI par rapport à CGI c'est que le serveur de requêtes est persistant. Donc on peut avoir son process qui périodiquement met à jour les informations qui s'y prêtent et les délivre à tout allure à la demande de la myriade d'utilisateurs. Du coup je m'installe OCamlNet et cgi_template, et codouille codouille, dans la foulée je dépile même un peu ma TODO list liquidsoap..
En tout cas avec ces conneries je suis encore tout éveillé, mais va sérieusement falloir que je me mette en veille.
2 commentaires:
Ok!
Moi ce que je te propose, c'est d'en profiter pour faire aussi kkes outils userland très importants comme yes, cat, tail, head, more, ...
Ensuite tu peux aussi coder un serveur X, et un gestionnaire de Desktop.
Aussi pendant que tu y est, poourquoi pas un kernel... Ha c'est vrai, Sam est deja sur le coup..!!
Bon ben ta plus qu'à finaliser ça: OcamlX, le premier OS tout en Caml!
Pas chaud? :)
Romain
Par
Anonyme, Ã 21/10/05 10:09
Wah l'autre, comment il charrie :p Va falloir que je nettoie ce post je sens..
Bon mais X et compagnie c'est des trucs éprouvés qui marchent bien. Par contre le web c'est plein de trucs qui marchent pas, des bugs, des failles astucieuses. Alors plutôt que d'utiliser des langages mous qui font plein de trucs dans mon dos, je m'attache à Caml.
Pour la rapidité ya pas photo non plus entre php et caml, sauf que dix fois epsilon ça reste gérable quand epsilon est petit comme ici.. et donc dans un langage interprété ça irait, bien sûr.
La vérité aussi c'est que je fais plein de Caml en ce moment, peut être plus que de français :)
Un autre argument c'est que je pourrais direct mettre un serveur FastCGI dans un process liquidsoap via un plugin grâce à OCamlNet. Je suis pas sûr de faire ça.
Par
mrpingouin, Ã 21/10/05 10:39
Un commentaire ?
< Accueil