Almost a year ago I suggested adding a couple of columns to acs_objects (See http://openacs.org/forums/message-view?message_id=75455.
Apart from that discussion I had a few more and most people expressed approval. However before "TIP"ping I want to solicit updated opinions.
In short, we have learnt how to use the object model two years after it has been conceived of, we know its advantages and disadvantages. It generally is fit for packages that exist on its own.
It is not yet really ready for site-wide services like:
- a well-performing site-wide search (the one in Oracle doesn't work)
- a generic linking module
- a notification service that works on all packages
So we have a unified permissions model, but not yet a unified model of retrieving the package_id or the name of an object. PL/SQL or PGSQL is not an option here because it does not perform (look up above thread), hence my suggestion to add package_id and object_name to acs_objects.
An object of a particular type is currently usually only shown within its package's scope although for a user it doesn't matter at all whether he looks at a calendar item, a bugtracker ticket, or an address. On the web everything is a link. A centrally stored package_id and name would enable *every* package to create a link to this particular object_id.
Central services would not only be more efficient in terms of CPU and IO consumption, we'd also get a lot more efficient in programming: E.g. when extending notifications towards a new module I don't necessarily need to know the internals of the package's data model, it is probably enough to look at acs_objects.
However there was at least one unresolved issue: I18N. Don made a great suggestion when Tilmann and I were chatting with him: objects whose name needs to be localized would have the message_key as their name.
And when touching acs_objects now, what other site-wide information may be lacking there?
E.g. when I told Tilmann community_id might be cool there as well - in DotLrn every object eventually belongs to a community, right? - I got a big honking no.
What about archived_p if we think about an archiving service?
Which columns' definition is not clear or not clear enough? E. g. what does last_modified mean for forum posting? The last_modified date for first question or for the particular answer?
Once we are through with this (the second time), I'll tip it.