Neophytos mailed me a copy of a new bboard package he has been working on. I will ask if he wants to place a copy where other people can review it, or if I can put up a copy.
I worked on a reimplementation of the bboard for a project at aD, when
ACS 4 just came out last year, and I had some thoughts about design.
Philg's original mechanism for the core bboard message threading data model (the one that's in
ACS 3.4) is actually pretty optimal, and doesn't rely on CONNECT BY,
which in turn has issues with sorting.
I am not sure if anyone has really tested the ACS 4 bboard (Oracle) for scalability of the data models with large numbers of forums and messages. They may have, I just don't know.
In any case, I found the current ACS BBoard module, with its dependencies on the acs-messaging, notifications, and content-repository, to be rather hard to work with. It is templated, which
is a big win, but I feel that the extra layers of abstraction that were added did more to increase the complexity and to make it more difficult to tune and debug the implementations, especially when you
want to customize the code.
So, I think returning to a simpler and flatter design would make sense. We should re-examine the goal of reusable code for general-comments, and for email notifications (both immediate and digestified) and see if there is some way to provide that without
making something that is difficult to work with.
I think the content repository is a useful idea for more conventional "publishing" types of tasks, but unless there is
a substantially simpler API to use it, it is overkill for the bboard,
and may have performance issues.
email notifications
