Absolutely not. Unless someone wants to pay me to do this full-time, of course. As it is, unfortunately, I have very little free time, and I can only devote a portion of that to developing Poseidon. I've spent a huge amount of time working on the new version, but there's still a long way to go.

Actually, yes! You've been sneaking looks at the CVS repository, haven't you? Since this is such a huge release in terms of new functionality, I'm planning to release several betas before officially declaring this version stable, but when it does stabilize, it will be version 1.0. Of course, the beta process could take quite a while; there's a huge number of new features that need testing, and it's important that I have a chance to get feedback from plugin developers on the new plugin API before declaring that stable, since the plugin API is something that needs to remain consistent for a long time to come.

Poseidon has always been more of a blog engine than a content management system, and that's where its strength lies, but blog engines have come a long way since the last Poseidon release. When I first began writing Poseidon, there were basically two types of bloggers: the casual blogger, who just wanted a basic website with basic functionality, and the uber-blogger, who wanted the website to do absolutely everything. Poseidon was aimed at casual bloggers, and it provided a good set of features for a typical blog.

Things have changed a lot since then. There's a new middle ground between the casual and the uber-blogger. An entire blogging community has sprung up, and blog engines these days perform a lot of functions previously relegated to content management systems. Some of them try to do too much, and that can be a bad thing, but it became increasingly clear to me that Poseidon just didn't do enough.

The biggest change people will see in Poseidon is that, out of the box, it looks and behaves more like a conventional modern-day blog engine, such as WordPress or Textpattern. However, as always, the goal of Poseidon is to provide the features you would expect and need in a blog engine, but never at the expense of simplicity or performance.

One big improvement over previous versions is how flexible the new Poseidon is. The new theme system gives you complete control over the design and layout of your site, well beyond what you could achieve by merely customizing the stylesheet. You can even change the way certain aspects of Poseidon work without needing to do any major coding and without breaking compatibility with future versions.

In addition, Poseidon will be easier to install and configure; no more mucking around in config files. A new modular database abstraction layer provides complete database independence, meaning you're no longer tied to MySQL. MySQL will still be the default database due to its popularity, but I'm planning to include an SQLite database module with the first release, and I hope to add a PostgreSQL module not long after.

Plugins are much more powerful as well. More on that later.

I've abandoned the concept of user "types" in favor of a simpler, more powerful flag-based permissions system. To give a user the ability to moderate comments, for example, you'd just set the appropriate flag on that user's account. Behind the scenes, it's all just done with bitwise comparisons, which gives us a lot of flexibility.

This also extends to blog posts and website pages, which have their own set of permission flags.

It'll blow 'em out of the water. Sorry, that sounds arrogant, but it's true. Most popular blog engines these days have absolutely horrendous performance, but there's not much complaining because it's just not an issue for most people. The vast majority of blogs don't get enough traffic for performance to matter. But that's a sorry excuse for developers to ignore the problem.

A few weeks ago, I tried to find some benchmark results to give me an idea of how other blog engines performed. There really haven't been any professional performance comparisons of blog software, which is surprising. I did find a few numbers, but they were so low I didn't believe them at first.

There's a project called LightPress, a modified version of WordPress, which claims to be the fastest PHP-based blog engine. I nearly spewed Coke all over my laptop when I saw their benchmark results: 6.51 requests per second (153.681ms per request). That's horrible!

I had been stressing out because Poseidon was generating 20 pages per second, which I thought was too slow. I figured someone must have made a mistake, so I downloaded WordPress, wrote a script to dump my Poseidon database into the WordPress database to give it some content to render, and benchmarked it myself. Sure enough, WordPress maxed out at 3 to 4 pages per second.

Of course, Poseidon isn't finished yet but all of the components tested by these benchmarks are already in place. Since those initial benchmarks, Poseidon's performance has actually improved to an average of 29.11 requests per second (34.352ms per request).

Of course, I wasn't satisfied with those numbers, so I wrote a modular page caching system that allows developers to write their own pluggable cache handlers for Poseidon. I then wrote two cache handlers, one that uses the filesystem as the cache store and one that uses memcached. With the filesystem cache, Poseidon shoots up to 125.94 requests per second (7.94ms per request). Using memcache, it's slightly slower at 110 requests per second (9.091ms per request), but memcache would scale better across multiple servers.

I don't have any plans, at the moment, to provide a "real" internationalization mechanism, mainly because I just don't have the time or the resources to devote to it, but one side effect of the new theme system is that it would be very easy to create translated versions of a site. I'd estimate that it wouldn't take more than an hour or two to translate an entire theme, and that theme wouldn't become obsolete with newer versions of Poseidon (with the exception of major versions, of course, in which I reserve the right to break backward-compatibility if necessary).

In addition, the UTF-8 character set is used whenever possible, to allow for languages with non-European characters.

There are a lot of changes, but upgrading won't be too painful. Poseidon will come with a tool to automatically import old databases, so existing content, comments, and user accounts will not be lost. Plugins, however, will not be compatible, and links will need to be updated to deal with the revised URL format, but I'm going to do my best to provide tools to make the migration as painless as possible.

Poseidon 1.0 should really be thought of as a completely different program from Poseidon 0.6.1. They share a name, and they share some of the same concepts, but that's about all.

That all depends on how the blogger configures their site. If you wanted to, you could make Poseidon 1.0 look and behave so similarly to Poseidon 0.6.1 that your users wouldn't even notice the change. In the default configuration, of course, the two will look very different. Poseidon 1.0 has a more crisp, refined design that, frankly, looks more like a conventional blog than the older Poseidon interface. It's what most users expect these days, and I think it makes it easier for people to use the site, since they already know how other blogs work.

Basically, it allows Poseidon to provide content management features while still focusing on being a blog engine. A post is a typical blog post, and is displayed as such. Posts can contain markup, images, and can be commented on by users (unless the comment flag is turned off). Pages, on the other hand, are intended to act as separate pages within the site. They share the design of the website, but they can contain PHP code in addition to markup, and they exist as single entities rather than in typical blog post format. Pages cannot be commented on by users.

One concept I'm toying with is the capability for pages to exist in a hierarchy, so that one page could have multiple children. For example, I might have a "Software" page on my site, and each of my software projects might be a child of that page, with other children of their own for documentation, downloads, etc. These pages could be managed in a wiki-like fashion (albeit not world-editable), and would be fully indexed and searchable along with the rest of the content on the site.

There's still a lot of work to be done on the plugin architecture, but the basic structure is already there, along with a few proof of concept plugins I've written. Plugins are one of many areas where Poseidon really takes advantage of the object-oriented capabilities of PHP5.

Writing a plugin is as simple as extending the PoseidonPlugin class and then hooking into the features of Poseidon that you want to use. Mechanisms will be provided for plugins to perform installation and uninstallation routines, such as setting up databases or creating custom pages or menu items. An event model will allow plugins to capture and act on Poseidon events. Plugins can even register themselves as filters, so that Poseidon will pass content (or even the entire generated page) to them for manipulation before being displayed.

In fact, if you wanted to take the lazy route of internationalizing your site, you could just write a plugin to filter everything through Babelfish.

Well, the "categories" table stores names and descriptions of categories, while the "posts_categories" table provides a mapping between posts and categories, so that posts can be linked to multiple categories.

Categories were one of the features most often requested by Poseidon users.

Ah, you're referring to the "sessions" table in the database. Actually, this isn't anything new. It just stores a unique hash, which is tied to a user's account when they log in and then saved in a cookie. When the user visits the site again, we look up the cookie hash in the database to authenticate that user. Older versions of Poseidon worked the same way, but the hash was stored in the "users" table. Putting the session hash in its own table results in a slightly faster database lookup, since it's a query that happens on every hit when a user is logged in.

I think it's the greatest thing since sliced bread. But then, sliced bread only serves an average of 15 to 20 slices per loaf, so it's hardly a fair comparison.