I was only responding to your last comment and Henry's earlier comments regarding the usage of the content repository for storing bboard messages.
I've been working with the CR lately, and while I agree that it has a complicated interface, I've found that you can get by with a very small subset of that interface to tie a package's content storage into the content repository. I've looked at the bboard code and it appears that the bboard package is not a very sophisticated user of the CR. bboard messages are stored in the content repository, and the bboard package also provides the capablity to attach images or files to bboard messages. That's it. Unless, I've missed something, you really only need a handful of api calls to implement the bboard interface to the CR.
On the other hand, as Henry suggests, it seems likely that there will be performance problems with the CR. All content revisions are stored in a single table regardless of whether they are live or not, so over time, the cr_revisions table could grow to be quite large, which could lead to performance problems.
I'm not saying we shouldn't consider redesigning the CR, but I think we should at the minimum, port the existing packages and evaluate them first before we go off and change them. Porting a package like bboard is trivial, so it seems like a waste to change it before we know how well it does or doesn't work.
There's alot of good ideas in acs 4.x, and I think we should try and find out which ones work well before we change things.
