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.