Cowpoke: Goals and Features
Cowpoke, as it currently stands, was never designed or intended to be a replacement for a system such as PHPNuke. It's more like a "WikiWikiWeb", in that it's basically a collaborative editing system for content, then displays the content in a uniform fashion.
However, the similarities end basically there. We don't use any form of "Wikicode" or anything like that, and a lot of the standard wiki features are gone. Instead, we use XML to store and process a subset of HTML that allows a lot of freedom, but seriously limits an author's ability to ruin the structure of their document.
Database and Performance
Being written entirely in the C programming language, and being optimized constantly to squeeze every last bit of performance, Cowpoke is very efficient and scalable in and of itself. You will probably need to upgrade your database server prior to needing to load-share your web server - especially if you're able to use things like a multi-threaded Apache.
Most of the binaries used to run the site actually spend less than half a second in execution, much of the time it's lots less - execution times measured in the hundredths of seconds are not uncommon.
Where most of the time is spent, however, is waiting for the database engine to process the queries in order to drive the pages. Many of the queries needed are simple, in fact any given page typically requires about 15 small queries, with small (many single row) result sets. These are simply used to setup sessions, pull preferences, and compile statistics.
Viewing any page requires exactly one query, however our current view page uses another query to count the comments on each article - which shouldn't hinder performance in any drastic measure; if it does, a prune of the Talkback database is probably necessary.
Our database systems aren't designed for speed as a primary concern however, data accuracy and flexibility are the primary design criteria. Our database of choice is PostgreSQL, because it scales in a sane manner, performs well, is feature rich and free. The entire engine is portable though, and most ANSI-SQL compliant database can theoretically be supported - simply write a new "db_" module to wrap your chose SQL database's functions in and compile. We try our best to maintain only 100% ANSI-compatible SQL.
If Cowpoke's performance ever begins to degrade, an update of the database server will become necessary. We haven't reached that point yet.
When it comes time to load-balance the web servers, Cowpoke should perform amicably right out of the box. Sessions and everything else are stored in the database, so simply install Cowpoke's front-end on another webserver, give it access to the database, and assign a hostname at it. Note that there is currently no method for replicating images, downloads or other non-content.
Markup and Display
Our chief concerns with output are compatability, structure, and legibility. The engine does it's very best to not output HTML which will confuse one browser or another, and it also attempts to output HTML which translates well to other formats.
The skin engine allows users to customize the interface of the website using CSS, much like many other sites, however the site will still function completely in a browser that doesn't support CSS (even one that doesn't support graphics). Our pages are completely viewable in Lynx/links, archaic Netscape/MSIE browsers, and others. All pages should be viewable on browsers for handheld devices. A WAP mirror is in the works.
Politeness
An important part of the design process for Cowpoke was for it to behave like a polite webserver. Too many webservers out there are terribly rude these days. You can't go to the front page of many websites without being bombarded with several cookies - Cowpoke will only offer a cookie when it's necessary to establish a connection. Cowpoke also strives to obey the various HTTP response codes - a missing file will emit a 404 response, and we support the IF-MODIFIED-SINCE request header, to cut down on cached traffic.
Overall Goal
Our overall goal is to continue to improve upon a system which takes the effort out of maintaining a large document tree, with minimal impact on server performance. We like to think we're doing pretty well.
There are still some parts that could be made easier, and the current XML parser could be a bit more friendly in pointing out errors, but it's getting there.