Some more applications that would benefit a lot from centrally available object data:
- The user contributions page
- Categorization (to browse through categories)
- Search (I repeat it deliberately since it is so important in my opinion)
- Calendar with arbitrary objects attached to events
- ...
If some basic object data would be available via the acs_objects table that allowed any application to efficiently render a list of objects without knowing about the implementation of each particular object type, then these applications would become feasible and OpenACS would gain a lot from the central integration that the object model already offers to a good extent.
The discussion about this stalled last time because of i18n issues with acs_objects.name. Don's idea of optionally putting a #message_key# in there instead of normal text (allowing both) seems like the optimal solution. Background: some object names must be translatable, otherwise they make no sense. Other objects are so infrequently seen by the user, such as acs_rels, that they don't need to be translated. Again other objects have a genuine name that doesn't need translation, e.g. a file-storage file could save the uploaded filename as acs_object.name.
creation_date and last_modified_date are both already there but sometimes such as in the case of forums they are not used in a way that makes them usable for general listings - it would be good if we could define exactly what last_modified means and make packages adhere to that standard. Then it could be displayed in search results for example (don't you just like to look into that forum thread first that was updated yesterday instead of the one last updated in 2000?). And this example shows also why it would be benefitial to have it directly in the acs_objects table, instead of a pl/sql function or a service contract: based on age (current_date-last_modifed) search results could be sorted and ranked. These are all needed features of a good site-wide search, that makes it superior to indexing from the outside.
Yes, the package_id would be the mother package. I don't understand the question to be honest - every object has a package that created it, no? Can you think of an example that doesn't? And the main point is that the package_id allows for guaranteed dispatching to the code that knows how to display it and where. Objects will always be obviously related to their creation package, and no, a package is not just another object, as I see it it is also a bunch of code and a location in the site-map which knows how to deal with its objects.
context_id is only used for the security hierarchy, and I have heard a number of times that it should actually be called security_context_id and not used for anything else, although I can't recall the rationale behind that right now. Anyway I think it would be much more efficient to have the (maybe somewhat redundant) package_id in acs_objects too, compared to having to do a 'connect by' all the time.
Another field that might make sense in acs_objects would be the subsite_id - opinions on that? It would allow for quick filtering e.g. of search results or objects attached to calendar items to be only from the current subsite.
