From CherryPy to Yaws

 This Apache versus Yaws comparison (click on the image!) is often quoted by Erlang believers. Of course, such high capabilities are totally insane for my humble Web sites. Still, Yaws is a nice opportunity or excuse I have to deepen my understanding of Erlang matters.

How it went

Here are a few comments, after three months of Yaws experience (this started 2008-05-30). See the following sections for the full story.
A sure thing, Yaws required just no maintenance at all. Not that CherryPy required so much either. The worst was the need of regularly processing the logs, which were filling up the disks every few months. I do not save Yaws logs.
After the move, I've been fully overwhelmed with other duties, both in my personal life and in my computer life. So, the no-maintenance of Yaws has been really welcome! Once again, I might soon find some more free time, as I'm progressively un-burying myself and digging up towards the surface…
Another thing is that Yaws is a bit less demanding on memory resources. CherryPy was using 120M (21M resident) of virtual storage, Yaws asks for 26M (23M resident). But this comparison is not completely fair, as I got foreign Python code imported in CherryPy to do dynamic generation of many Web pages. These pages did not really need to be dynamically generated, so for Yaws, all these pages are pre-generated. One might say that it is more inviting for a long-time Python user to abuse of CherryPy's facilities than Yaws' ones ☺.

Introduction

I'm rather satisfied with CherryPy as a way to support most of my Web sites. My configuration progressively grew over the years, it is still fairly tractable, and I do not have to touch it often. On the other hand, while CherryPy is fairly elegant in its way to trigger various processors, exploring URL path elements from left to right, I lost part of that elegance for addressing the various needs I had. There is some complexity in the class hierarchy representing all my Web sites, and in the various redefinitions of methods, sometimes for fundamental CherryPy operations.
So, the whole thing would suffer some cleanup, nothing extraordinary, just for getting back the original elegance designed into CherryPy. In that respect, an overall switch from CherryPy to Yaws is total overkill, but as I'm interested in getting acquainted more deeply with Erlang in practical contexts, this switch is a kind of good exercise for me.
The difficulties to foresee is that Python is processing most of my Web pages at delivery-time (through a templating language of my own). This processing falls within these categories:

• consistently shaping page headers, footers and menus
• reformatting README, TODO, NEWS and THANKS
• dynamically serving files, archives and email folders
• producing a presentation of my blog entries
• serving a few slide shows (index and succession)
• peeking (at one place) into my database of musical scores

Implementation

For now I'll accumulate thoughts and remarks here as I go! ☺

• The first step has been to create the skeleton of a yaws.conf file, abusing of <opaque> for saving information. It comes from CherryPy configuration sources, in the form of assignments to class variables or instance variables. This editing work was also a quick survey of all the work waiting ahead.

• Most pages for all sites were created on the fly through Traiter and Python, to account for differences in site addresses, template locations, logo formats, and various other parameters. Yet, for most of them, any given page was to be generated the same. So, to better separate Python processing and future Erlang processing, I opted for a pre-computation of static pages in Python mode, to take care of consistently shaping page headers, footers and menus, and dynamically serving files and archives (Yaws does it). A single common Makefile was linked into many places, including for each a site.mk file to account for the differences, taking them out of the Yaws <opaque> declarations. An overall Makefile was made to launch all that static generation, per host, driven by all the docroot lines of the related Yaws configuration file. Finally, I managed so the generated static pages do not get synchronized between machines, as they differ.

• The blog tool I use (Pyblosxsom) is also full Python, and relies on docutils on the fly. I once quickly kludged a link into the blog tool from CherryPy, maybe this is also a good occasion of thinking this whole area afresh, once more. Yet for now, I got rid of Pyblosxsom by merely generating the blog statically, after an entry is added or edited. As end readers may not edit it, it it not a true blog anyway. I merely wrote a tiny Python script for combining and dating entries, and I even get a new table of contents for free. This takes care of producing a presentation of my blog entries

• The above was enough in my opinion, despite the remaining glitches, for switching to Yaws in the current state of things. This provides service in work-around mode for reformatting README, TODO, NEWS and THANKS and dynamically serving email folders. The first four kind of files are fairly readable as they stand anyway, so this is even quite acceptable. However, it is admittedly very rough to present the email folders in their original mbox format, yet it's better than nothing. All these are to be improved on later, of course, by recovering the previous presentation from CherryPy's times.

• The remaining points are currently broken, and postponed: serving a few slide shows (index and succession) and peeking (at one place) into my database of musical scores

With some luck, I'll find some free time to play in these areas. But free time, I get only a few drops here and there in these days.

Brève biographie

 Aujourd'hui, on fait flotter le verre fondu sur une mer lourde de titane en fusion, et en refroidissant le tout ensemble, on obtient des fenêtres très planes. Mais j'apprécie le charme de l'imperfection des verres d'autrefois, comme dans les fenêtres de chez moi. En voici deux, l'une réfléchissant l'autre.

Le texte suivant est extrait de la présentation de ma conférence sur Remsync, au RISQ, en 1995

François a fait quelques études en informatique à l'Université de Montréal, avant de travailler comme administrateur système à divers endroits, dont le Centre de Calcul de l'Université, la Société de Mathématiques Appliquées, le Centre Informatique de Dorval. Il a enseigné aux petits et aux grands, ici ou aux États-Unis, et depuis toujours, il réalise divers travaux en informatique. Quelques-uns le perçoivent un peu comme le fantôme de l'Opéra.

D'ailleurs, ses intérêts extra-informatiques vont principalement vers l'orgue et la musique d'orgue. Certains connaissent François pour la bataille qu'il mène en faveur de la langue française, qu'il veut protéger du mauvais sort que l'informatique lui fait subir. Présentement à l'emploi de sa société, les Progiciels BPI, c'est son implication dans le projet GNU qui l'amène à nous parler aujourd'hui.

En, fait, cette brève biographie apparaissait comme une rubrique du menu de mon site Web personnel principal, qui contient une version plus complète de ma biographie. Ce blogue pourra m'aider, j'espère, à rendre mon site principal un peu moins lourd: il m'offre un moyen de placer l'information hors du chemin, sans toutefois la perdre!

Souvenirs du DIRO

 La première parution de l'Écho du DIRO renouvelé rendait compte d'un party de retrouvailles des anciens du Département d'informatique et de recherche opérationnelle de l'Université de Montréal et, chose amusante pour moi, illustrait ce party d'une photo où j'apparais (à gauche). On y voit aussi Francine Ouellette (de dos), Jacques Lefebvre (au centre) et Claude Goutier (à droite). En cliquant sur cette photo, on peut rejoindre la parution de l'Écho du DIRO dans son entier.

Malgré que je ne sois pas académicien de profession, j'ai toujours eu une relation un peu bizarre avec l'Université de Montréal, et réciproquement. C'est là que j'ai eu mon tout premier emploi, dans ce qui s'appelait alors le Centre de Calcul (et qui évolué de diverses manières depuis pour devenir la DGTIC d'aujourd'hui). Plusieurs années après que j'aie quitté cet emploi, l'Université a longtemps continué à m'attribuer un bureau, et ainsi, facilité mes fréquentes visites et diverses collaborations par la suite. (Il faudrait bien que je complète quelques détails à ce sujet, l'un de ces jours.)

Sur les CDC-6000 du Centre de Calcul, j'étais l'usager no 6. Claude Goutier a repris ce numéro lorsqu'il m'a remplacé dans le poste que j'occupais, et je suis devenu l'usager no 16 pour toute la durée du projet BONJOUR, et bien au-delà. Au DIRO (Département d'informatique et de recherche opérationnelle), mon code pinard existe depuis mes études, et dure encore. Je m'en sers parfois pour faire des tests, généralement juste pour avoir une autre vision sur le réseau, mais rarement pour les ressources de calcul qui y sont associées. Par contre, l'adresse de courriel (ainsi que la paramétrisation du compte qui sous-tend cette adresse) sert vraiment beaucoup, puisque pinard@iro.umontreal.ca a toujours été la seule adresse de courriel que je publie officiellement! Je l'ai toujours gardée comme référence, malgré qu'au fur et à mesure de mes emplois, contrats ou activités et collaborations dans divers projets ou laboratoires, j'ai bénéficié d'un bon nombre d'autres adresses, que j'ai tenues discrètes la plupart du temps. Mon courriel au DIRO, c'est mon adresse rémanente ☺.

Bernard Derval me demandait un jour jusqu'à quand, approximativement, je prévois utiliser pinard au DIRO, ce à quoi je lui avais alors répondu: Jusqu'à mon irrécupérable sénilité. Mais il m'est difficile de prédire, même de manière approximative, à quel moment cela se produira. Remarque que mes amis proches, peut-être, ont des opinions plus précises que moi à ce sujet, que leur politesse empêche de me partager? ☺