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 | +