Caching static web content with Seaside

Given that it looks as though ircbrowse has gone away permanently, I decided to write my own little client for viewing the logs of the #squeak IRC channel. Fortunately most of the hard work had already been done at http://tunes.org/~nef/logs/squeak/, but as the site itself notes: "these logs are purposely "raw" and are intended to be parsed/reformated/wrapped before viewing."

So I put together a client in Squeak and Seaside, currently viewable at http://mykdavies.seasidehosting.st/seaside/my/irclog to do that for me. While I was doing so, I got a bit carried away and added some extra features:

• All lines can be colourised based on the author's nick
• It attempts to recognise HTTP URLs and converts them to links
• Each message timestamp is an anchor, so you can link to a given message
• At certain times there's a lot of chat in Spanish on the channel, so I added in-page translation capabilities using the Google Ajax Translate API.
• Key session parameters are added to the URL, so that they are maintained even when the session has expired.

Now, once you've added all these great features, you end up with a massive page that's complex to generate, but once it is generated most of the content remains static. There's not a great deal that I can do about the initial generation (except get rid of some of the functionality), but surely I can cache that content?

I searched the Seaside mailing lists, but generally responses tended to point out that caching of static content should be handed off to the front-end web server. There were two problems here -- first, the page wasn't going to be totally static, just the content from a single component. Second, I wanted to put this application on seasidehosting.st, so I wouldn't have this option available to me anyway.

They say that once you get a hammer, every problem looks like a nail, so I wrote a Seaside solution: a simple caching component using the decorator pattern that checks to see if the content requested is already in the cache, and if not it asks the owner component to generate it. This proved to be very effective; the profiler showed that a non-cached page was taking around 2-3 seconds to generate, but with the HTML cached, this dropped to a handful of milliseconds. 

Given that this approach can substantially reduce the server load even when the page as a whole isn't static, I was surprised not to find something like this in Seaside already, is it too trivial? -- please let me know in the comments if I missed something obvious.

There's nothing particularly clever about the class once you've worked out that all the html that has been generated at any point in time is accessible via html context document stream. However, this approach requires A WARNING -- no session information must be used within the cached components -- no forms, no dynamic links, no Scriptaculous functions. Also, be careful about use of html nextId in the cached component - there is no guarantee that such IDs will be unique when incorporated into a document from the cache.

Anyway here's how it works. The component in question is wrapped in an application-specific subclass of a caching decorator component that:

1. Maintains a cache dictionary as a class instance variable.
2. Requires the owner class to implement a #key method that provides a unique key for each page, and also an inst-var called shouldCache (with associated accessors).
3. Implements #renderContentOn: that 
1. Checks if the requested page is in the dictionary (using the #key method).
   
2. If so, stream the cached content to the current renderer and return.
   
3. If not, notes the current html context document stream position.
   
4. Sends #renderContentOn: to the owner.
   
5. In this method, the owner then renders as normal, and resets shouldCache if it doesn't want the current page to be cached (ie if it is still subject to change).
4. Control then returns to the decorator. If shouldCache is still set, this checks the html context document stream to find all the content that the child added, and copies it into its own cache, and exits.

And that's it!

Using Apache as a front-end for Seaside

I'll admit it, configuring Apache scares the bejeezus out of me. The documentation seems to be so focused on the trees, that the wood becomes an impenetrable, gloomy forest. I guess I'm not alone in this, which makes Ramon Leon's posts on configuring Apache with Seaside(1, 2, 3) so useful.

Despite this, I've still steered clear of going near Apache, until Ramon posted a sample extract of configuration text. Now, cut-and-paste is something I can do, so I decided to give it a go.

I'm on Mac OS X, so Apache is installed and running by default. Despite my earlier protestations, I have played with Apache before, so I knew that httpd.conf was the key file to control how Apache runs. A bit of poking about in man files uncovered the location of the file I needed: /private/etc/apache2/http.conf.

I opened a Terminal and cd'ed to /private/etc/apache2/ where I could execute sudo vi httpd.conf which prompted me to enter my password to edit this administrator file, and then allowed me to start hacking. I wanted to leave my existing configuration as untouched as possible, so below the line:

Listen 80

I added a new line:

Listen 81

which would start Apache listening on port 81 as well as port 80. I could then use port 81 for my experimentation.

Typing sudo /usr/sbin/apachectl restart caused Apache to restart, hopefully loading my change.

I then tried browsing http://localhost:81/

Success (so far) - Apache is trying to deal with my request, and using its default handler.

Now, I'd noticed an interesting line at the bottom of httpd.conf:

Include /private/etc/apache2/other/*.conf

which meant that I could make any other changes in a separate file. So sudo vi other/seaside.conf opened a new .conf file, into which I typed:

virtualhost>

    #ServerName yoursite.com

    #DocumentRoot /var/www/myExamplePath

    RewriteEngine On

    ProxyRequests Off

    ProxyPreserveHost On

    UseCanonicalName Off

    # if the path doesn't exist, rewrite it to be a Seaside file ref

    RewriteRule ^/seaside/files(.*)$ http://localhost:8080/seaside/files$1 [P,L]

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f

    # redirect all requests to seaside - configure this as required

    RewriteRule ^/(.*)$ http://localhost:8080/seaside/$1 [P,L]

/virtualhost>

Which (when you put back the angle brackets that Blogger eats on the first and last lines) is taken directly from Ramon's post. It does two useful things. It takes any requests coming in to port 81, and first checks to see if you're requesting a physical file, and if so, serves it up (useful for the static parts of your site). If not, it passes them on to Seaside on the appropriate port, adding the standard /seaside prefix (so this is hidden from the outside world, which is a nice touch). Restarting Apache again and this time browsing http://localhost:81/examples/counter got me:

Again, good news. However, when I tried to navigate around, or use applications that made use of built-in #style and #script methods, things started to go wrong. The reason here is that Seaside prefixes its generated relative URLs with /seaside. So I simply added the following:

# re-write all requests starting with seaside - these links are exposed
# by the application internally. Alternatively, you can
# re-configure Seaside to change the urls it generates.
RewriteRule ^/seaside/(.*)$ http://localhost:8080/seaside/$1 [P,L]

into the virtualhost directive, and re-started Apache once more. This time it all worked like clockwork.

Twenty minutes of not very challenging experimentation, and I now have Apache working as my front-end webserver. That means, all the handling of static files can be done outside of Squeak, I can configure my responses if the Squeak images crashes, I get access to all of Apache's features such as logging, SSL etc. Not a bad half-hour's work really.

Magritte vs Seaside

I'm just starting to experiment with using Magritte and Seaside in Squeak, and it's proving to be interesting if slightly hard going!

I think where I've got to with Magritte is that it's best thought of as a tool for building "edit" screens for objects (a task that it does very effectively under Seaside), but if you're trying to do anything else with your object, then it's back to plain old Seaside!

What I was trying to do was to put Magritte descriptions on an object subclassed from WAComponent, to allow me to use asComponent addValidatedForm to edit the object, but also use renderContentOn: to display the object. However, Magritte relies on a number of introduced messages on Object that WAComponent defines independently.

What I've had to do is introduce a 'wrapper' object to handle the view. This seems a bit cumbersome, but I've had a look at another Seaside/Matisse application — Conrad, a conference attendee management application developed by Stéphane Ducasse — and that appears to be the approach that he took. "Appears to be" as I'm having the usual problem of working out which way is up when looking at new code!