In ACS 3.x, each messaging application (e.g. bboard, general comments, spam, ticket tracker and so on) used its own specialized data model for representing and manipulating messages. ACS Messages provides a common data model and API for these applications. The service provides the following common mechanisms:
Messaging applications constitute some of the most useful forms of web collaboration. Many of the application packages that have been developed for ACS have a messaging component. Therefore, ACS Messaging provides a standard set of abstractions for storing, sending and receiving messages through a web service. Our goal is to support a diverse group of messaging applications through a single centralized facility.
The ACS Messaging package defines a data model and API for the storage and retrieval of messages. While the package standarizes how messages are stored, applications may use any data model they want for higher level organization of messages into threads, forums, and so on. ACS Messaging places no organizational constraints on client applications.
The package consists of the following components:
ACS Messaging is generally not used directly by users, so there are no user interface level scenarios to consider at this point. It's possible that in the future we will want to extend the system with generic administrative user interfaces, but this is not clear right now.
We scenarios that we should consider are the kinds of applications that we mean to support with this package, and what the developers of those applications would like to see in the data model and API.
The following applications in ACS 3.x could have been implemented using this package:
Each of these applications requires a message store and each defines it's own high level organization for messages whithin that store.
The main requirement of the ACS Messages package is to support this diverse set of applications with a common infrastructure. This is because all of these applications would like the following kinds of common functionality:
10.0 Message Store
ACS Messages should provide a single store for objects representing messages.
20.0 Message Content
A message should have a primary content body consisting of a specified MIME type and a block of storage holding the content. In addition, applications may store one or more seperate revisions of a message.
30.0 Attachments
Messages may be composed of additional attachments. Each attachment should be tagged with a MIME type to indicate what type of data is stored there. Each attachment can only be attached to a single parent message. In addition, the system must be able to store one or more revisions of each attachment.
40.0 Unique ID
Messages should have universally unique identifiers to allow global reference and RFC-822 compliance.
50.0 Sender
Messages should be related to the sending party.
60.0 Threading
The system model simple message threads, that is chains of messages that are replies to each other. If message M is a reply to some other message N, then M should be able to refer to N in a straightforward way.
70.0 Search
Messages should be searchable as part of a site wide search. Therefore, the data model must integrate with the data model for site wide search.
80.0 Messages
The system should provide the following interfaces for manipulating messages:
80.10 Creation
Applications should be able to create new messages objects.
80.20 Revisions
Applications should be able to create a new revision of a given message object.
80.30 Deletion
Applications should be able to delete a message and all of its revisions and attachments. (is this true?).
80.40 Type Checking Applications should be able to check whether or not a given object is a message.
90.0 Message Attachments
The system should provide the following interfaces for manipulating message attachments.
90.10 Creation
Applications should be able to create new message attachments and connect to their parent object.
90.20 Revisions
Applications should be able to create a new revision of a given attachment.
90.30 MIME Types
Each attachment should have a MIME type. The system should be able in principle to deal with an arbitrary collection of MIME types, although initial implementations may be more limited.
100.0 Messages and E-Mail
The system should provide the following interfaces for integrating with existing E-mail systems. Note that these requirements only deal with sending mail. Our feeling that a seperate package should be implemented to deal with receiving mail that would use ACS Messages for storage of incoming messages.
100.10 Sending Single Messages
The system should provide a mechanism for specifying that a message should be sent as outgoing E-mail. Outgoing messages should be queued so that the system can maintain auditing information to deal with transport failures and so on.
100.20 Sending MIME Messages
The system should be able to send messages with attachments as multipart MIME messages.
100.30 Sending Digests
The system should be able to group multiple messages together as a single e-mail digest. For example, all the messages in a single bboard thread could be sent to a user as a digest.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 10/04/2000 | Anukul Kapoor |
| 0.2 | Edited and extended for more general data model | 11/07/2000 | Pete Su |