snowsprint3

Prompted by Jon Stahl’s entry on the PloneBlog I want to point you to one of the more tangible results of my participation in this year’s Snow Sprint, namely Plone Improvement Proposal (PLIP) #128 a.k.a. Pluggable Plone Syndication – the collective brainchild of Ben Ackland and Rick Hurst from Netsight, Nate Aune and yours truly.

The idea behind it is to get rid of the necessity for dedicated blog products and blog-specific content types in Plone and to treat blogging less like a product and more as a use case. To this end we’ve started to create generic feed templates using Zope3 views, interfaces and adapters (via Five) for all ATCT types and a clean way for 3rd-party developers to create adapters for their content types (i.e. ATAudio to create podcasts).

After initial struggles with the new Zope3 approach (and lots of wrestling with Jean-Francoir’s and Russ’s z3-enabled-branch of ATCT – thanks for your patience, guys!) we’re happy to have been able to implement a working proof-of-concept by the very last day of the sprint ;-)

What now remains is lots of cleaning up and polishing. Ben has already contacted me about getting that underway, but since we’re both swamped with paying-the-rent type of work, we don’t expect to get back to that until next week. For those of you interested in the project, I suggest subscribing to the RSS-feed of our changelog. Any feedback is more than welcome – if we get this one right, Plone could become the über-blogsoftware ;-)

At the sprint I’ve been setting up and tearing down various Zope instances all the time using my instaPlone script. Due to the nature of a sprint I’ve been able to improve it thanks to the collective wisdom of everybody who was unfortunate enough to sit near me while tinkering with it. Extra props to Jodok from lovely systems who pointed out two neat and important aspects of configuring your caches in zope.conf.

Basically, you can use the cache-size directive in two different contexts inside the zope.conf when configuring a mount point: once on the same level where you specify the mountpoint and once where you specify the ZEO instance, that will be mounted there. The crux is, that the parameter has a different meaning for each context. In the latter case (zeo client) the parameter refers to the size of the cache-file on disk that’s created for this connection. In the first case (mount point) it refers to the number of objects to cache in RAM – and the default is 4000. This means, that if you have, say, 4000 images inside your ZODB of 1Mb each, the Zope server could eat up to 4Gb of RAM. One word: ouch! So Jodok advised to set it to saner value, such as 400. But, of course, YMMV and finding a practical value depends on the average size and total number of objects in your ZODB. An advanced usage he suggests for large sites is to create an explicit mount point for the portal_catalog and assign it a large cache-size (say, 100.000) because the catalog contains lots of tiny objects and a more conservative number for the rest.

In the timid hope to make any sense at all, here’s the zope.conf snippet that I now use for instaPlone:

<zodb_db main>
    mount-point /
    cache-size 400
    <zeoclient>
        server localhost:$ZEOPORT
        storage 1
        name zeostorage
        var $INSTANCE/var
        cache-size 25Mb
    </zeoclient>
</zodb_db>

Oh, and here’s the updated version of instaPlone. It now uses Plone 2.1.2, creates symbolic links to the Plone products in order to conserve disk space (and significantly speed up execution), and of course, incorporates the new, saner cache-size values.

I’m currently developing an Archetypes-based Product which will need to implement lots of relations among its content objects and I sort of brought it with me as a “pet project” to the sprint. Because as I was happily implementing those relations using ATCT and ATReferences I suddenly realized (with horror!) that these relationships are not preserved upon export and import using the standard .zexp method!

At first glance what seems to happen is that (at the very least) upon import the content objects receive a new UID, so any reference to that object will now point to a non-existing object.

This is a big issue – fortunately, some folks smarter than myself are already working on it. And that’s another example of how incredibly useful such a sprint can be: I was able to ask jensens (the maintainer of Archetypes) about it and he alerted me to XMLForest. It’s currently not yet in a releasable state (it depends on modifications to the Marshall product that currently are still incompatible with Plone 2.1.2).

I’m now trying to help the author Gogo to hunt down the bugs – I’m not in the position (yet?) to actually fix them because I simply haven’t got enough knowledge about the inner workings of Archetypes but at least I’m very diligent in hunting them down and reporting them – and it’s really a good feeling to be able to contribute back, even just a little.

Personally, the snow sprint started off with a bit of a shock. Upon arrival at the location I did two things: try to post a blog entry and check my email. First I find out, that I can’t post any blog entries – plone ignores the changes?! At the same time I got email from three clients who report that they can’t edit any content on their plone sites – which, incidentially, are hosted on the very same machine as this blog…

The symptoms (listed to increase the likelihood of somebody experiencing them finding this entry ;-) were that editing or creating any content object in plone that involved a certain amount of data would fail: either the creation would fail with an error message regarding missing data (a.ka. "Title is required") or the modification would just result in an actually unmodifed object and Plone lying out of its teeth claiming, that all changes had been saved.

Luckily I was in the best possible company imaginable to solve such a problem ;-) Matt a.k.a. Hammertoe was kind enough to help me narrow down the problem. Pretty soon we had isolated it to Apache, rather than Zope or Plone itself. Luckily Matt had encountered a very similar problem and immediately remembered, that it was due to a bug specifically in apache version 2.55. Which made sense, because we upgraded our apache just a few days ago…

Fortunately the bug has already been fixed in the trunk and in the 2.0.x-branch. The remaining problem was then to build the new modules specifically on FreeBSD. For future reference (who knows when that will come in handy!) here are the steps:

• cd /tmp
• svn checkout http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x
• cd /usr/ports/www/apache20
• make clean
• cp /tmp/2.0.x/modules/proxy/* work/httpd-2.0.55/modules/ don’t replace the folder as that would remove the config information – just copy the files from svn into the proxy directory!
• make deinstall ; make reinstall
• sudo /usr/local/etc/rc.d/apache.sh restart
• write emails to client informing them, that problem is fixed
• post to tomster.org

Thanks again, Matt for the hand-holding ;-)

Ah, day one of my “geek week” has arrived! I’m writing this entry while riding a super smooth intercity train from Zurich to St. Margarethen where I and four other sprint attendees will (hopefully) be met by our lovely hosts.

2006 has been incredibly busy for my wife and me – both of our workloads have just gone through the roof and so part of me is actually a bit sad, because during the course of the upcoming week I will get to see even less of her and the kids. But at the same time I’m already beginning to really enjoy spending some quality, continuous hacking time. For one thing – and this is an absolute novelty! – I’ll be having my mobile phone switched off for the entire duration of the sprint. I’ve recorded a voice mail informing any callers about how to reach the folks who are watching my back while I’m gone so I can rest assured that everything will be taken care of during my absence. After five years of running tomster.org as a one-man-show and maneuvering myself into that awkward corner called ‘indispensable’ I’ve finally been fortunate enough to be part of a team of admin-colleagues. While each of us still works independently we’ve reached a level of familiarity now where we can blindly trust each other.

To sum it up: this snow sprint marks the first occasion in five years of me really being able to take a break from being a self-employed family father a.k.a “from it all™”. I can only imagine, what it will be like to spend more than just a day hacking – but, as they say: “there’s only one way to find out!”

Update: the entire trip went incredibly smoothly and we’ve arrived at Lovely System’s offices. And if I hadn’t been up drinking vodka with Cryx and Erdgeist till 2am this morning despite having to get up again at 3:30am to catch my plane I might actually do something now… you know… something else than taking a nap noon and feeling incredibly old...