More notes in preparation:
A: discuss solutions to named objects archictural problem and produce TIP for voting
details (corrections welcome, of course):
The category package reveals a flaw in the OpenACS architecture, and instead of working around it in category, which is problematic, we should address it head-on. Using category as a use case, here is the problem:
Some use cases for categories involve showing a list of openacs objects, such as all objects in a category. In order to display such a list, the OpenACS core API provides for acs_object__name for each object, which is actually several layers of abstraction in both SQL and TCL. However, the performance is unacceptable and this is probably a structural problem. We also need a URL for each item, and the OpenACS core API does not provide for this.
Category solves this problem by creating an acs_named_objects table. This is a denormalized table containing object names. This table is empty, however, and the details of filling it will vary by package. Thus, anybody who installs category cannot use functions that use this table unless they also change every other package in OpenACS.
Category solves the URL problem by "using /o/OBJID to defer URL lookups. so it's ok if its a slow function lookup since it's only done one object at time when someone clicks on a link" (jcdldn).
Solution 1: Make acs_named_objects a core table; document the work required per package to populate it; do this work for the core packages.
Solution 2: Today packages create their own implementation of acs_object__name which is called by acs_object__name. The value of this function is typically something package-specific, or something trivial like "Object #123456". Packages should have triggers on the table where the data ultimately comes from that update acs_objects.name or acs_named_objects, in lieu of true functional indexes on acs_object__name. (guan)