Forum OpenACS Q&A: Response to Name Change
Jerry, I'll give it a shot. This is a very rough description, but this will be good because people will be able to comment on it and I can develop my idea further. It will also be good material to develop the competitive analysis.
I don't have any experience with PHPgroupware and little with Zope, but I have spoken to many Zope advocates or users and have read their docs.
Zope was developed entirely with an object oriented philosophy. The basic idea is that a web page is a collection of data that should be broken down and stored in a DB. If one were to consider each part of a content page as objects, for instance text as an object, images as an object, etc., then it would make sense to store them in an ODB. That way, you don't have to specify the data type and you save some time and energy writing a lot of SQL tables.
If your site is just content and you're not doing a lot of writes to the DB, this is a great philosophy. Many of the successful commercial CMS systems out there do it like this as well, including UserLand which is very similar to Zope. It's also more or less the approach ACS 4 uses in the content repository and with acs-ojects.
This approach, though, also means that you are pretty much considering that content is the core of your system. If you're not doing a lot of writes, then you're probably not doing a lot of tracking of your users or implementing very sophisticated interactive functionality. This is pretty much a design or implementation decision and for certain projects it's probably the most appropriate.
To implement more complicated systems, or to get much more scalability out of a system, Zope can connect to third party DB's like Postgres or Oracle. You can build a datamodel with those systems, but Zope still treats them as objects in the application engine. So, near as I can tell, Zope takes data as an object, converts it to something that the RDB can read and stores it there. Then when it needs it, it makes the query for the data, converts back into an object and plays with it. This could be nice, but it creates an abstraction layer between the DB and the server that I don't quite trust. It's mixing an Object Oriented paradigm with a Relational paradigm in a way that seems either dangerous or overly complicated to me. I would ask someone who is more technical to comment on this.
The ACS approaches web systems differently. I suppose Philip began the system with Photo.net thinking what is really important is not the content administrators select and provide, but the content the community develops and present. As a result, the most important thing is to build a consistent data model that describes the user in a very general, flexible and powerful way. The functions, like bboards and CMS, are generally solved problems or easy to solve so let's worry about those later.
The result is that if you're building a system that needs to organize and arrange data not according to content but about or by users, the ACS is extremely effective. You don't have to reinvent the wheel in describing what the user looks like and how it interacts with the existing functionality, but only how to implement your specific needs.
The example that I use for clients to describe why we think the ACS is cool is a donor management system (it's the story I know best, not a marketing ploy. honest). Musea wants to work with non-profit organizations to build database systems that organize their donors. Because each visitor to their site is a potential donor, you want to be able to compare the visitor DB vs. the donor DB. If they are a donor, you also want to know what they did at your site so that you can either approach them for funding for a particular project or mention you are starting a new project somewhere else and would they like to help there?
Building a system for donor management is very easy in the ACS because we already have a data model for describing users and user groups and it is our responsibility to build customer relationship rules and workflow for how those donors should be managed. The result is that you have a system with a single DB that includes visitors to the website and donors and tracks not only how much they've given, but what they've contributed to the community interested in this subject, all in a relational table(s) in the RDB.
With Zope, it's not clear you could roll out the appropriate data model that could work across the all the functions and modules in gathering all the info about the donor and then presenting it in a single interface to an admin.
Furthermore, ACS4 made a big step in solving the CMS problems of earlier versions with things like the aforementioned content repository and acs-objects. So what has traditionally been the big weakness of the ACS now has a solution that just needs a reasonable implementation.
These are my initial thoughts. Anybody that has a point they want to make, please do it. If we ought to start a separate discussion let's do that too.
talli
