First of all I would like to say that I am very glad to see that the
OpenACS community has so many great minds who are willing to pick up
with the design of the ACS object model where ArsDigita left off
more than a year ago!
I agree with Lars that time to learn, time to develop with and
performance are objectives that should be given top-priority. I also worked at ArsDigita so I have witnessed just how devastating over-engineering can be.
Here are my conclusions from this thread so far:
- In the interest of being able to write generic services all
user supplied content should be an ACS object. This conclusion rests
on the assumption that the performance penalty from using tables
with a huge number of rows is negligible or at least acceptable. I think
Don Baccus puts it very well:
"So in short any information in the system that is meant to be used in a
general way should be an object. Only items that are tightly controlled
within an application and that aren't meant to be exposed to other
packages (search being another example) should be non-object tables."
- The performance problems with the permissions API can somehow
be dealt with by excluding ACS Objects that don't need
permissioning (i.e. Bboard posts) from the permission tables
(by means of a flag or otherwise, see Barry Brooks post above).
- To be able to easily, scalably and generically
write crucial services such as site-wide search and the "what's new"
page, the columns name and url should be added to acs_objects.
While I am writing about acs_object columns I should mention that I
have started a thread on the topic of a logic site hierarchy
here.
