I've been working on a vastly simplified class/object data model. Probably one of the most fundamental concepts used to simplify programming is to use abstractions and avoid special cases as distinct building blocks. As an example, a number of the base tables in OpenACS are not object tables, so code which deals with them are special. In my model, I have an object table, a class table and a mapping table (and optionally an object extension table). Classes are objects, and every object has a class. (Object 1 is of class 'class', it is self referential). The maps are not objects, several fields are used as the primary key. This simple model supports versioning, tagging, multiple hierarchies per object, archiving, logging, etc. These features can be applied after the fact, or removed. You can join objects in new ways without changing the class models. You can attach any object to any other object, so it would be easy to add a comment class and use it with every other object class.
Anyway, I just had a thought, more for myself I'm sure, but until now I was thinking how incompatible this model is with OpenACS, in other words, what would be the point of creating an OpenACS package with this datamodel. But maybe I could reverse things a bit and make a few changes to OpenACS so that everything sits on top of this model. Probably not too much code would be required to add a 'create object' function for the acs_objects table, which would get its id from my object table. Then I could use my system to create objects distinct from OpenACS, but still use the features when necessary.
The XoTCL code would have an easy time with this datamodel, as the whole point is to leverage generic methods for reuse. Of course, the same will be true for Tcl and pl code...
