OpenACS

It doesn't take too much work to remember the dot-com era, back when you could get financing for a company that did almost anything. At the beginning of that period, when the Internet was becoming a mainstream medium, there was a lot of talk about on-line communities. These sorts of communities weren't new to internet veterans, who had been participating in Usenet long before the Web appeared on the scene. But they looked like an excellent opportunity to the venture capitalists and entrepreneurs, who saw on-line communities as a potentially huge market.

As was the case with many such ideas, everything was great except for the business model. Many thousands of on-line communities exist today, all of which make it possible for people from around the world to share information and ideas on a topic. Although few sites have managed to build businesses around such communities, there is no doubt that such software is a vital part of today's web infrastructure.

Creating an on-line community using a relational database and a programming language is not difficult—but creating your tenth web/database user-management system in as many months is annoying for the developer and expensive for clients. Moreover, what happens when a site wants to add new functionality? It would be nice if the new features and fixed bugs could be reflected in all of your sites, rather than only the one on which you made the changes.

Philip Greenspun, author of the wonderful Philip and Alex's Guide to Web Publishing, realized all of this back in the mid-1990s, when marrying the Web and databases was still a relatively new idea. His solution was to create a set of applications that took into account the needs of as many on-line communities as possible. The software toolkit he created formed the basis of his doctoral thesis at MIT. It was also the basis for ArsDigita, the web consulting company he founded. When the ArsDigita Community System (ACS) was finally released, Greenspun made it available under the GNU General Public License (GPL).

Like many web consulting firms, ArsDigita never quite lived up to its promise. After several years of meteoric success, investors were brought in to expand the company further. Greenspun was forced out; the company released two half-baked versions of ACS (including one in Java that essentially rewrote the entire system); most of the staff was laid off, and finally, Red Hat (which was backed by the same investors as ArsDigita) hired a handful of programmers and bought the company's few remaining assets.

If ArsDigita had been a proprietary software company, then this would have been the end of the story. But because ACS was licensed under the GPL, the community took over where the company left off. More significantly, the community already had been working on a version of ACS, known as OpenACS, that would use the PostgreSQL relational database rather than the ACS default, Oracle. (This article assumes that you will want to use PostgreSQL; the instructions are only slightly different if you wish to use Oracle.)

OpenACS 4.5, as the first production release was labeled, was released in June of this year. It was renamed the “Open Architecture Community System” to reflect the fact that ArsDigita is no more. But Greenspun's influence is profoundly felt in the OpenACS community, and the wealth of code and documentation written by ArsDigita employees have helped propel the project forward.

This month, we begin an extended look at OpenACS, which is one of the more powerful (if relatively unknown) open-source web toolkits available today. In coming months, we will look at how to install OpenACS, how to use its templating system to create dynamic pages and how to create sophisticated on-line communities with limited code and administration.

It's easy to say that OpenACS is a toolkit for creating on-line communities. But what does that mean? For starters, it means that OpenACS comes with working versions of most of the applications you're likely to want on a community web site. It handles user registration and administration, forums, FAQs, groups (including a rich permission scheme), news updates, file storage and distribution, personal home pages, surveys and a web-based calendar. As you might expect from a modern system, administration of the applications is done almost completely through the Web, with only a few configuration files.

An experienced developer probably could write some or all of these applications within a few weeks or months. But why reinvent the wheel? Moreover, OpenACS is built on collective experience gained from building such communities, which is reflected in the sophistication of the data model and applications.

From a developer's perspective, OpenACS provides a database designed for the creation of new, integrated applications. This data model actually is the most important part of OpenACS. Although you could rewrite the software for another database (as has been done with PostgreSQL) and even use a language other than the default Tcl, the data model is where most of the system's smarts lie. OpenACS provides Tcl and Pl/PgSQL procedures that make it easy to work with the data model.

Because OpenACS relies so heavily on a relational database, it is important that access to the database be efficient and flexible. For this reason, OpenACS installations almost always use AOLserver (introduced in last month's installment of At the Forge), instead of the more popular Apache. Because AOLserver uses multiple threads inside of a single server process, it can provide a shared pool of database connections. (Although there is fairly strong allegiance to AOLserver within the OpenACS community, I would not be surprised if the introduction of multithreading Apache 2.0 eventually leads the project in that direction.) And while AOLserver provides its own database API, OpenACS provides a number of higher-level procedures that make it extremely easy to work with a database.

If you plan to work with only a single brand of database, then you can use these procedures directly inside your Tcl programs to store and retrieve information. But to ensure that all applications will work on all platforms, OpenACS encourages developers to place all of their database queries inside specially formatted XML files (with an .xql extension), with each file corresponding to a single database. When a Tcl program invokes a procedure to send a query to the database, the OpenACS “query dispatcher” opens the XML file for the currently configured database, reads the query and sends it to the database. An OpenACS system written in this way should be able to switch from PostgreSQL to Oracle merely by changing the top-level configuration file,

As we saw last month, AOLserver comes with its own templating system, known as ADP, that makes it easy to mix server-side programs with static HTML on a single page. Of course, this means that designers and programmers often are fighting for control of a single file, so designers must know which sections of a page to avoid. OpenACS thus includes a new, more advanced templating system that breaks each page into two parts: a Tcl page that sets variables and an ADP page that retrieves those variable values. This approach is similar in some ways to Zope Page Templates (ZPT) and Enhydra's XMLC.