Is this a places that a stricter definition of/ distinction between "service" vs. "package" would help over the long run? It seems like we often get caught up in providing APIs to developers and UI's for users all in the same piece of code. I really like Ben's idea that the core should not be too smart... it should allow programmers and even site designers (installers of packages) to do stuff that is "dumb". <br><br>
I guess the issue here is which parts are the toolkit-- building blocks-- and which parts are applications. The toolkit parts of the bboard would include functions-- allow different looks and feels, email integrations, tie to the content repository to access advanced functionality, etc. Some functions are delivered by the bboard package, some are delivered by other packages through the bboard package (email for instance).<br><br>
The application... an actual place to post messages with a user interface and a place within the navigation structure of the site is an entirely different creature composed of a UI and logic that assembles all the functions in the "correct" way. That application could put together the functions provided by the toolkit in ways that may or may not make sense-- allowing innovation and many different applications that do the same basic thing built off of the same toolkit.<br><br>
I'm not sure that this means that bboard somehow becomes two packages-- the toolkit and the application-- just that the code within the package is segregated in such a way that folks can differentiate between the toolkit parts and the application parts.<br><br>
Not being a developer, please enlighten me if I have missed some fundimental way that this does not make sense.
