BBoard and ACS Messaging update

We have released a more featureful bboard (4.0a2) to the ACS package repository. download it here. You'll also need to upgrade your acs-messaging package to use it.

The new version supports limited alerts and threading amongst other refinements.

I'm going to try to keep this status page up to date on our schedule and where bboard is.

As always, please report any feature requests or bugs through the SDM page for bboard.

-- Anukul Kapoor, November 2, 2000

Answers

Can somebody please outline the planned role of the ACS Messaging package? At my last check, the ACS Messaging package was simply a wrapper for the content repository with an additional mapping table. Now it looks like a basic email queue has been added. I still struggle to find a compelling reason to use the acs-messaging package as:

• It is not clear from the requirements/design documents what the overall plan for this module is

• acs-messaging locks us into storing the content of the message in the content repository. This does not let us use the acs-messaging package for dynamically generated email messages that do not need to be stored in the database (e.g. sending user's passwords when they request). Should this package be general enough to handle these common cases?

• how will the acs-messaging package interact with a generic email handler? are there plans for a generic email spammer/handler?

I guess the fundamental question I have trouble answering is "What set of requirements does the acs-messaging package satisfy?" The answer to this questions can help us to evaluate when we should use the acs-messaging package.

-- Michael Bryzek, November 2, 2000

I'm glad you asked, Michael. John and I haven't done a good job at articulating what acs-messaging is about and the documentation I have produced is rather weak. This stuff has been trapped in the heads of a few people rather than being discussed out here.

acs-messaging was born out of the design of the new bboard. One thing we discovered when researching requirements for bboard and discussion software in general was that there are a variety of ways one may wish to structure and organize threads of messages e.g. in discrete forums with tagged categories, attached to other user objects annotated with user ratings, etc.,. Our design addressed this by separating the store of messages from the organizational data model and any user interfaces.

acs-messaging is then a layer built atop the content repository that provides a more constraining set of semantics, semantics one can build functionality against. I can write code that displays a message, forward a message, compile a set of messages into a digest, displays a specific attachment, etc., that can be reused in bboard, webmail, and general comments. We can maintain user preferences on HTML vs. text email, inline attachments vs. URLs across the system, and have simple procedures that do the right thing when sending email. Another example: if we built the IMAP server functionality 3.4 webmail provides against acs-messaging, then bboard forums, pages of comments, and webmail folders could be viewed uniformly through your email client. The IMAP mapping isn't quite trivial, but you can see the idea.

To reiterate, if applications are storing the same sort of data (a text-ish messages with optional attachments and replies), they should store them the same way. Then code from particular applications can possibly be refactored into generic functionality.

To answer your specific question, spam/general alerts/etc isn't meant to be replaced by acs-messaging, at least not with what is there currently. Currently it is just a store; but we intende that it be the canonical store for messages that need to be stored in the database. If messages automatically generated from other user objects need to be queue'd up or archived, they should do so in the acs-messaging tables. We can implement the generic incoming email system by stashing messages in acs-messaging, then dispatching the message id to package specific code for processing.

Right now acs-messaging is very slim; it just supports bboard. We intend to add attachments (most likely implemented as content repository items that are children of the message), extensible headers (just like the webmail datamodel), and possibly versioning (as provided by the content repository) since Phong expressed a desire for this.

I hope this gives you an idea of what it is for, where it is going, and why general comments might want to use it. If you or anyone reading this has any questions, please ask them on this bboard.

-- Anukul Kapoor, November 6, 2000

General-comments has the following features:

• A comment can be associated to any object in the system.
• Comments associated to the same object can be further separated into categories.
• Comments are implemented as content-repository items.
• A comment can have any number of attachments (files, pictures, hyperlinks), which are implemented as child content-repository items.
• Has revisioning provided by the content-repository.
• Has a user interface to view/edit/delete comments.

I suggest that we combine acs-messaging and general-comments together. The new acs-messaging would provide the features that Anukul mentioned. Bboard would still be built on top of this new acs-messaging, and general-comments would then be a small set of UI pages to create acs-messages. An alpha release of general-comments will be out later tonight.

-- Phong Nguyen, November 6, 2000

Phong: Your proposal is in principle a good idea, and is pretty much what John and Anukul would like to see happening with acs-messaging.

I'd like to suggest that before we release something called an "alpha" that you send the code for general comments to Anukul and John Prevost for review so that we can work out a good strategy for the integration.

I'd also like to ask if you have specifications and documentation for the general comments module that you have developed. A big goal for the development of 4.0 modules was to have reasonably complete documentation well before the code is released. Having docs would also help the process of designing the right way to integrate acs-messaging and general comments. Bboard and acs-messaging have been behind on this due to scheduling constraints, it would be nice to get it on the right track, and a spec of what your general comments module does would be a good start.

Can we set up a conference call for tomorrow, sometime after the ACS group meeting to talk about this? Maybe around 4pm EST?

-- Peter Su, November 6, 2000