ACS Messaging Requirements

by Anukul Kapoor and Pete Su This is only a DRAFT

I. Introduction

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:

• A single data model for representing message objects. Message objects model electronic messages between users of a collaborative system. Mail messages, USENET news messages, Bboard messages, user comments are all examples of applications that might use message objects.
• Storage of message objects.
• Central support for attachments, threading, and search.
• Mechanisms for sending and receiving message objects as e-mail.

II. Vision Statement

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.

III. System/Application Overview

The ACS Messaging package defines a data model and API for the storage and retrieval of messages. While the package standardizes 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:

• A data model for representing and storing messages.
• A data model for representing and storing attachments to messages.
• A mechanism for sending messages as e-mail.
• A mechanism for integrating the message store into site wide search.

IV. Use-cases and User Scenarios

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:

• BBoard
• Webmail
• General Comments
• Spam
• Various parts of the ticket tracker.

Each of these applications requires a message store and each defines its own high-level organization for messages within that store.

• Bboard organizes messages into forums and categories and threads. It also allows users to send and reply to messages via e-mail.
• Webmail organizes messages into mail folders.
• General comments attaches messages to objects representing static or other content.
• Spam queues messages and sends them to groups of people as e-mail.

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:

• Reply chaining and threading.
• Messages with attachments of various types.
• Representing messages as multipart MIME e-mail.
• Queuing and sending messages as e-mail.

V. Related Links

• Design Document

VI.A Requirements: Datamodel

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 separate 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.

VI.B Requirements: API

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 separate 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.

VII. Revision History

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

---

Last modified: $‌Id: requirements.html,v 1.3.2.2 2024/08/01 07:38:16 gustafn Exp $