Content Management Systems (CMS) are a way of handling lots of different users interacting with lots of different data in lots of different ways. A CMS is a robust solution to user interaction and the information they are interacting around. There is a broad range of CMS system capabilities if we consider platform-dependent applications that have been developed within industry. Looking specifically with the web space there are essentially content management frameworks, which create a foundation upon which is built functionality like storage, editing, display, etc. A sub-structuring of these CMS options has been suggested4.1 to consist of four general categories:

• Content management frameworks: As mentioned, these are mini 'platforms' upon which a wide range of functionality can be built. some consider them the be akin to a programming toolkit. It is an especially relevant metaphor considering that using a product that implements a content management framework requires the site developer to know a fair bit of programming.
• Page-based systems: These products generally mimic the file / folder metaphor that a user is familiar with in using a computer. They allow a reasonable skilled general computer user to create a site with little programming knowledge. Modifying these system require extensive programming knowledge, though.
• Module-based systems: These systems focus on collections of code (modules) that can be added to the system and configured with little effort. They are very focused on the way that each module handles its data, and have interfaces that are jigsaw assemblages of these interaction models. As the case is often that many different developers contribute the modules, the programming styles are different and end users of even reasonable programming knowledge must spend some effort to edit the modules. All others must use the modules as they come.
• Content object systems: These systems focus on the ability fro content to be designated as a discrete "atom" in the system, and moved around or displayed in different contexts based upon that metaphor.

These categorization are most relevant to the perspective of a user choosing a solution for their website. The developer perspective is that in reality all of these systems can with little trouble be divided into two categories: those that use content management frameworks, and those that don't. Those that don't are often very customized for a specific workflow, or use a model of inter-object communication. Having the code of individual models talk to each other does not scale well, some operational models are generally impossible to implement, and in practice the code across all the modules is very messy (bordering on "nightmarish").

CMS products that do use content management frameworks can scale well and are easier for robust development - but come at the cost of expertise. Editing them requires good developers. In most cases, the basic content management framework provides basic functions like workflow, templating and personalization - but requires everything else to be custom written. In most cases each of these products have their own pre-built package, but as always, some modification will probably be necessary. These systems are often costly to setup, and are usually used by large organizations.

Content management frameworks are further divided into two main categories, based upon design model:

• Application Servers: This design model implements a full data server as part of the product. Some implementations handle data storage, data server (like a web server), and other capabilities in addition to the framework. Perhaps the most prominent in this category is Zope15.7
• Content Servers: Primarily, this design model involves the modification of Apache, an ubiquitous web content server, to support a dynamic language, such as Perl, PHP, or another. This approach is the foundation for many popular packages, such as Drupal5.24, TikiWiki13.31, PostNuke9 , and TikiPro13.55. Other products that create their own content server are generally commercial, or are not sophisticated in their development at the present.

To date, most Content Servers utilize a rudimentary content management framework, which is largely a result of their being built on top of a high-level development language like PHP. Creating a full-featured framework would slow down the CMS too much, and as a result most CMS products in their category offer a thin framework, if any. PostNuke (and siblings) offer no content management framework, replying instead upon object-style inter-module communication. Again, this does not scale well. Other CMS products create a base framework to handle low-level coordination like variables, paths, and some data structures - though many still rely heavily upon inter-module communication, or the collective assertion that a specific module will assume framework-like capacities.

The basic architecture of Zope, TikiWiki, TikiPro and Drupal will be covered below. These products were selected because they are the most widely adopted. A brief story will illustrate these products at a glance:

TikiWiki, Drupal and TikiPro are like the three metaphorical brothers from Chinese tradition. TikiWiki is the oldest (most features), but is complicated and ornery for it. Drupal is the middle brother, drawing on the experience of its younger and older sibling it plots deeply (big plans). TikiPro is the youngest brother, and not being the front-runner it has the opportunity to learn much and is the wisest (best design model), but is the least developed. Zope is the Taoist monk who remains undefeated because none of the brothers can challenge him on his turf (different CMS model).

TikiWiki is a CMS that presents a wide range of features "out of the box." For this reason it is many peoples' CMS of Choice. For the individual, small company, or organization that is looking to make an ambitious step from a web site of mostly static documentation TikiWiki is the common choice (Drupal as well, which we shall get to later). Some developers have moved to TikiWiki due to the extreme learning curve of Zope. Comparatively, TikiWiki's home site is poorly designed for navigation and the documentation is frequently re-organized, and incomplete. (It is hoped that these are momentary growing pains.)

Basic Components:13.33

• Page: In the TikiWiki documentation, the term page is synonymous with Wiki page.
• Feature: A feature is a TikiWiki component that has a distinctive function, such as image galleries, file galleries, FAQs, banners, forums, blogs, etc.

A "feature" can be any of a wide array of things; from an Image Gallery or Interactive Map to a list of system variables and their state. A full feature list, as defined by the TikiWiki documentation, is provided below for the deeply interested. Some of the features under "Communications Tools" are quite compelling, and worth considering whether choosing between an existing CMS like TIkiWiki or creating one from scratch. TikiWiki has come to implement a wide number of features in a short period of time, and the speed of development has led to code design that is sometimes considered sloppy. Less so than PostNuke, but more than Drupal, some may characterize.

Features:13.19

Drupal seems to have cropped up in part response to TikiWiki and part to Zope. The development community seems to have a concern with making many of the jagged areas of TIkiWiki more soft, while still being within the learning curve of the general web hacking public (unlike Zope). Some of the basic features of Drupal are:5.11

Many more features are available through third-party contributions - as with all CMS systems. Drupal has a very clean 'interface' for the home distribution site that allows new users to get 'in the flow' of the way the software and its development community works. The product is perhaps not as full-featured as TikiWiki in their raw states, but it hold a great deal of promise and is one of the biggest competitors from this segment of the CMS 'market.'

TikiPro is a relative newcomer to the CMS scene, having grown out of the TIkiWIki source with the intent of being more architecturally stable than other PHP-based CMS solution. As such, it is comparatively sparse, but it's core foundation is simple and direct:

• Package: These pieces are features such as the WikiPackage or BlogsPackage. The term Package was introduced as a concept in TikiWiki by Dennis Hetzel. Prior in this document the term 'module' has been used in this sense.
• Modules: These are parts of a package that are laid out on a web page for display.
• Plugins: Plugins are the method that data is exchanged with the package. The LibertyPackage and WikiPackage both have their own plugin architecture to handle different data.

• Theme Style, feel, coloring
• Layout i.e. of package interfaces; positioning

• Low level package for storing all data in a unified database structure.

TikiPro makes a decisive move toward having all packages use the Liberty Data Integration package to coordinate information within the system.

PostNuke has grown to have an architecture very similar to the Tiki packages: 'module' based with templates to wrap things together. Its relatively widespread use is reflective of the fact that it was one of the first CMS systems to emerge in the public space. The architecture9.5 has not been cleanly developed over time, and as such it is not feasible for the scale of system that is being considered here. There is a two-sided coin to PostNuke's scalability problems: there is no core system module(s) that regulate the operation of all others, and there is no well-standardized protocol for all the 'modules' to talk with each other. These are problems loosely suffered by all the framework systems described above, but PostNuke particularly fails prey to these issues.

The Zope Application server is something of a departure from the mechanism of existing content management frameworks. It is in the process of evolving from something that looked much like the models described above to a system which is a true object-oriented component architecture. A full discussion of the object-oriented model will not be covered here, as it has been well discussed other places,1.9 and doing so often requires some length. Suffice to say that objects carry with them attributes, methods of communicating and dealing with other things. Difficulties in the system arise in coordinating and ensuring responsibilities for inter-object relationship. The similarities are so remarkably similar to inter-personal psychology and human relationships that people have questioned if the Object-Oriented programming has arisen primarily as a mirror of our mind, in much the same way that John von Neumann's characterization of the computer as a model for the brain carried with it such utility.

The content management framework model that Zope uses for its version 3 is an interpretation of the object model know as Component Architecture:15.53

• Services: components (i.e. objects) critical to the performance of a given task.
• Adapters: components that act as interconnecting joints between other components by providing an interface between them.
• Utilities: components that take the role of registries, being a clearinghouse for accessing data.
• Factories: components that largely have the role of creating other objects upon request.
• Presentation Components: a class of components that include Views, Resources, Skins, Layers - each of which is a different level of displaying the information that a component has to share.

The object model is fairly succinct, and versatile for handling a wide range of application scenarios. Consider the 2.x system, which is at work for most Zope users, and its similarities to the CMS frameworks utilized by the Tikis, Drupal, PostNuke, etc.:15

• Content Object
• Folders,
• Files, and
• Images
• Presentation Objects
• Zope Page Templates: content structuring including logic/conditionals
• DTML Objects: hybridized display/content
• Logic Objects
• Script (Python) Objects and
• External Methods
• SQL Methods: Another Kind of Logic Object

The overall structure is very prominently presented as an object-object oriented, especially considering the implementation of inheritance, an aspect of object models. With this 'old' model we can without too much effort project is similarly to the CMS models of Tiki, Drupal, etc, each of which use an inter-module communication model for their framework. It is in Zope 3 that a dramatic step is taken toward thoroughly implementing an object/component model.

Architecturally, TikiWiki, TikiPro, and Drupal are nearly identical - and depending on how far back one stands Zope could be a near cousin to the rest. All of these CMS products have moved toward an object-oriented model for their application, whether they call the objects "packages," "modules," "components" or otherwise. Now that we have covered the layout of each it become easier to see that the differences between these products is in how they implement objects. The Tikis, Drupal, PostNuke, etc are all written on top of languages that are procedural, or only thinly implement an object model themselves. Thus, for these programs to build object interaction on top of their 'support structure' is, at best, slow.

Could a true object structure be built? Sure; in the sense that C++, a popular object language, was built on top of C. Invariably, though, there is a little bit of overhead. This overhead is something that is maneuvered around by compiled languages through better compiler design - an avenue not as easy for the uncompelled script languages of PHP, ASP, etc. Zope avoids this problem by being written on top of Python, an object language with a long history of solid development.

Pragmatically, what is really being said here? Each of these languages is moving toward an object model and it is conceivable that they will all operate at comparable speed one day. Architecturally, as problem exists in how PHP & ASP run through code that sits 'inside' of the web server. This adds another delay in speed and a bottleneck that cannot be worked around through good network engineering.

Further, at the present time Python implements objects cleaner than other languages in its class (interpreted scripts). it sits at a unique position of having the object-functionality of a pre-compiled language (C++, Java, etc) yet being flexible like other languages that are executed on-the-fly. The mix of object design and interpreted execution has made Python (and Zope) a perennial favorite among academics and scholars, including its use at Google,8.6 Apple Computer, NASA, and others. Though other languages may in time develop to be contenders with Python, they are not at the state of maturity or acceptance to be used to implement projects of sufficient scale.

For this reason, if no other, it is clear that the Zope content management framework is the best choice through which to envision the system conceived and sketched earlier. As other options mature then reconsideration will be in order, particularly since it is the capability for fledgling languages to implement features easier than their elders. The developers for each of these language is working hard to envision what the 'next generation' language will look like. With the advent of server-side web-based applications the browser is becoming the new development platform, and the result is a feedback loop to the languages the support this new medium. Thus the products influence their production language. Roads are being laid for whole new distributed platforms, and the place of new collaborative systems to influence the way we consider this scale of communications technology is discussed more in the appendix The Broader Vision. Growth is perpetual.