LightPress

In the latest nightly build, together with lots of fixes and improvements. Getting ready for a 2.0 release.

I have just committed preliminary support for Lighttpd rewrite rules in LightPress. If you feel adventurous, you can download our development package and let us know of anything that needs fixing. I am not a Lighttpd expert, so any input is welcome.

Fresh from two weeks of holidays in beautiful Lanzarote, I tried to tackle the WP pages problem I outlined in my previous post. The result is a 150 lines patch for

, which brings rendering time down from 18 seconds to less than 1 second in my test blog with 200 pages. The patch is also available as a drop-in php file, but remember to backup the original WP file in case you run into problems later.

Just did a series of poor man's benchmarks against beta3, using Apache Benchmark with no concurrent requests (ab -n 100):

I am too lazy to install wp-cache, but using Sencer's benchmark to do the math we should be about 50% faster than wp-cache. I will try to find the time to install wp-cache on this machine and have some real numbers, but not before we release beta3.

Beta 3 is almost ready to be released, with two new important features: a regression testing engine that Jerome is developing which will allow us to thouroughly test new releases, and a new built-in caching system.

We already had a few caching objects lying around, but were missing an appropriate hook where to plug the cache. We now have the hook, and a sketch of the supporting WP plugin to configure the cache engine. The results are not so bad, as the speed with caching enabled is 8x the speed without caching, which should make us faster than wp-cache (did you have any doubt?).

What spurred us into action is an interesting thread on the wp-hackers mailing list (take the time to read Jason Hoffman's messages as they are worth it), and particularly a phrase by Matt which we hope won't hold true for long. :)

Just a short announcement about a few bugs in the latest beta. Most are minor and are either usability-related or affect how the plugin synchronizes WordPress and LightPress options. But there's a major one that will prevent Windows users from enjoying the new backend interface. It has to do with paths and escaping -- although that may sound like the basis for a great movie, trust me, it's not so exciting.

As the token Windows user on the team, it's normally my job to find these things and fix them. I apologize for letting you all down. If you really want to try the latest beta, why not try another OS at the same time? Or you could wait a few days until we release the next beta. [Or you can grab the wp-plugin/ folder from our anonymous CVS --ludo.] Your choice.

We have not disappeared. We are working on 1.1.0 beta 1 which will hopefully be released in the next few days, and will feature quite a few improvements and bug fixes over the latest 1.1.0 alpha release:

• seamless integration with WP's permalink options and automatic .htaccess generation

• support for nested pages (static posts in LP-speak) and categories

• no need to touch the filesystem (move/rename WP files, copy LP files, etc.)

There are lots of other exciting new features scheduled after beta 1. Stay tuned...

I'm progressing with the WP plugin for WordPress, which is the main thing missing before releasing 1.1.0-alpha1. It will alow users to set options, and activate/deactivate/configure plugins.

It's a lot of (boring) work, but seeing the LP console taking shape and knowing users will have a graphical install/configuration tool integrated with WP is pretty exciting. Stay tuned. :)

A few quick notes on the current status of development.

The mock-up for the "split" architecture involving a sort of mvc layout for Frontend did not go too well: the code is much more complex and, though more flexible in some situations, it also seems a bit slower so iI have abandoned it for the time being.

In the last couple of days I have concentrated on speed in the 1.0.0 maintenance branch:

• removed all PEAR dependencies and switched all classes to the PHP error system

• refactored Frontend to allow context-dependent queries before we fetch posts

• added a getLastModified() method to Frontend which checks the last modification date for the context posts and optionally comments

• added two caching classes

The Cache classes are a very clean db-based one which I like a lot and a filesystem-based one. Both classes give a 7x performance boost checking LastModified(), to do better we have to integrate with the WP backend like the excellent wp-cache does. The fs-class still needs work, and the integration with Frontend is sub-optimal. Will work a bit more on that in the next few days, if there's any interest. The new code can be found in CVS.

One of the benefits we might get from the new architecture I'm testing is a much more integrated and simpler feed management, so while adapting the current code to the new class layout I took the occasion to revise or support for Conditional Get.

I had already adapted Simon Willison's code to work around a bug in PHP's

formats (fixed in 4.3.11), but the code was a bit too complex for my tastes, and re-reading the relevant parts of the HTTP/1.1 specification, I noticed that full compliance requires supporting three different date formats, all in GMT:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123


Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036


Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.

HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields.

As LightPress stabilizes, we can start asking ourselves a few questions on its architecture, some of which Jerome and I have already discussed in private. Given the increasing interest in LightPress, I thought it better to move the development discussions here, to give readers the opportunity to influence our decisions.

The question I've been meditating this weekend is whether the current Frontend class is trying to do too many things at once, and if it would be better to split it into separate classes. I'm not trying to start a religious discussion on design patterns, OO vs functional programming, or leaky abstractions, I'm just wondering what (if) we would gain/lose from splitting Frontend into more manageable/consistent classes.

If you are not familiar with Frontend, you may notice by looking at this rough UML diagram that its methods are already split into categories: