ACS Message & BBoard Design Document

by Anukul Kapoor

I. Essentials

II. Introduction

bboard is an ACS application package built to provide scalable discussion forums to a community of users. As in older versions, bboard provides:

The initial 4.0 implementation adds the following new features:

The ACS 4.0 version of bboard is a re-engineering of the data model and presentation layer without certain capabilities present in the ACS 3.4 bboard. In future releases we intend to achieve the same level of maturity as the older bboard while building on the flexibility of the new design.

In particular this implementation (9/2000) does not include the following features found in prior versions:

bboard is not intended to be the ultimate customizable web based discussion system. It is intended to be a practical and useful system that supports forums much like the photo.net Q&A forum. Publishers with special needs are encouraged to implement their solution as a module, much like bboard, built atop the framework acs-messaging provides.

acs-messaging is a general purpose component that provides threaded messaging services to higher level applications such as bboard. The motivation is to provide a base level data model and reusable presentation code that enables the rapid customization of messaging applications. acs-messaging is intended to simplify modules like general comments and webmail, as well as specialized messaging applications such as scorecard's geospatial bboard. Such a framework keeps custom organizational metadata, pageflow and navigation, and publishing and moderation policy separate from the basic tools needed for discussion.

III. Historical Considerations

Over the course of ACS development, bboard has grown to encompass a wide variety of functionality. Much of this functionality was developed first for bboard and only later adapted into more general mechanisms (e.g. alerts, security, group scoping, etc.,). However bboard wasn't refactored to take advantage of the more general facilities, and its complexity challenged those in need of custom features. Furthermore there was a lot of ad hoc mechanism in both the data model and page flow to support different presentation styles, navigation schemes, and access control models. Although this bboard proved to be useful, scalable, and reliable, the ability to maintain and extend this code suffered.

The ACS 4.0 release of bboard mimics the basic functionality of older bboard versions but built atop new ACS 4.0 general mechanisms (objects, persmissions, templating, acs-messaging, etc.,).

.

IV. Competitive Analysis

An analysis of the bboard feature space should be added here.

V. Design Tradeoffs

How does one reconcile all the possible discussion forums mentioned above into a single module? One does not! bboard is precisely one way to implement a discussion forum and should not be all things. In time, there should be a toolkit of components (user interface, data model, and procedural) for developers to assemble their custom.

Although many of the entities in the data model are implemented as subtyples of ACS object, we avoid using information from the ACS object table for anything but auditing purposes. For example, we could store a message's author in the ACS object creation_user field, however to keep query performance in line we rather use the author field in acs_messages.

VI. API

As of the initial ACS 4.0 release, acs-messaging and bboard do not provide well defined programming interfaces.

Although convenience functions will be provided for basic transactions on the acs-messaging and bboard entities, it remains to be seen what sort of abstraction layer is most appropriate.

VII. Data Model Discussion

acs-messaging defines the view acs_messages_all for the storage and access of threaded text messages and assorted information relevant to their display, access, and creation. Under the covers acs-messaging use the content repository for underlying storage.

bboard uses acs-messaging messages, and organizes them into forums and categories. For the purposed of the ACS permissions system, forums contain messages, and so any permissions on a forum will default to being inherited for individual messages.

A forum may be designated as moderated, in which case explicit approvals or denials are stored in the bboard_message_moderation. Messages without entries in the moderation table are considered unseen, and will be displayed or hidden in moderated forums based on policy.

Each forum may have some number of categories, tags denoting further specialization within a forum. Messages of a forum may be tagged as being in any of the categories pertaining to that forum.

Permissions

Permissions in ACS 4.0 involve 3 interrelated hierarchies: users & groups, objects, and privileges. The user and group hiearchy is generally explained elsewhere. The short explanation:

The long explanation:
BBoard defines the following permissions:

VIII. User Interface

IX. Configuration/Parameters

X. Acceptance Tests

XI. Future Improvements/Areas of Likely Change

Much of the functionality of the ACS content repository will eventually provide tangible benefits to bboard and any acs-messaging application. Foremost among these features will be full text searching and rich media attachments.

When ACS provides a general mechanism for an installation to send and receive email, bboard can provide email alerts and email based reply and post.

XII. Authors

Anukul Kapoor

XIII. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 09/01/2000 Anukul Kapoor
0.2 Revision 09/19/2000 Anukul Kapoor


akk@arsdigita.com