Commit cd0f4f92 authored by Frank Bergmann's avatar Frank Bergmann

- OpenACS 5.9

parent 434ac311
......@@ -2,27 +2,27 @@
<!-- Generated by the OpenACS Package Manager -->
<package key="acs-messaging" url="http://openacs.org/repository/apm/packages/acs-messaging/" type="apm_service">
<package-name>Messaging</package-name>
<pretty-plural>Messaging Services</pretty-plural>
<package-name>ACS Messaging</package-name>
<pretty-plural>ACS Messaging Services</pretty-plural>
<initial-install-p>t</initial-install-p>
<singleton-p>t</singleton-p>
<version name="5.10.0d1" url="http://openacs.org/repository/download/apm/acs-messaging-5.10.0d1.apm">
<version name="5.9.0" url="http://openacs.org/repository/download/apm/acs-messaging-5.9.0.apm">
<owner url="mailto:akk+@cs.cmu.edu">Anukul Kapoor</owner>
<owner url="mailto:prevost@maya.com">John Prevost</owner>
<owner url="mailto:vinod@kurup.com">Vinod Kurup</owner>
<summary>General messaging for bboard and general comments.</summary>
<release-date>2013-09-08</release-date>
<release-date>2015-10-04</release-date>
<maturity>3</maturity>
<vendor url="http://openacs.org">OpenACS</vendor>
<license url="http://www.gnu.org/copyleft/gpl.html">GPL</license>
<description format="text/html">Provides generic message services, with email sending. acs-mail-lite and notifications are the
prefered packages for delivering this functionality and it is anticipated that this package will ultimately be deprecated.</description>
<provides url="acs-messaging" version="5.10.0d1"/>
<requires url="acs-content-repository" version="5.10.0d1"/>
<requires url="acs-kernel" version="5.10.0d1"/>
<requires url="acs-mail-lite" version="5.10.0d1"/>
<provides url="acs-messaging" version="5.9.0"/>
<requires url="acs-content-repository" version="5.9.0"/>
<requires url="acs-kernel" version="5.9.0"/>
<requires url="acs-mail-lite" version="5.9.0"/>
<callbacks>
</callbacks>
......
......@@ -11,3 +11,9 @@ ad_library {
# Schedule every 15 minutes
ad_schedule_proc -thread t 907 acs_messaging_process_queue
# Local variables:
# mode: tcl
# tcl-indent-level: 4
# indent-tabs-mode: nil
# End:
......@@ -44,7 +44,7 @@ ad_proc -public acs_messaging_format_as_html {
@param content Text to view
} {
if {$mime_type eq "text/plain"} {
set result "<pre>[ad_quotehtml $content]</pre>"
set result "<pre>[ns_quotehtml $content]</pre>"
} elseif {$mime_type eq "text/plain; format=flowed"} {
set result [ad_text_to_html -- $content]
} elseif {$mime_type eq "text/html"} {
......@@ -155,3 +155,9 @@ ad_proc -private acs_messaging_process_queue {
}
}
}
# Local variables:
# mode: tcl
# tcl-indent-level: 4
# indent-tabs-mode: nil
# End:
......@@ -34,3 +34,9 @@ aa_register_case acs_messaging_message_p {
}
}
# Local variables:
# mode: tcl
# tcl-indent-level: 4
# indent-tabs-mode: nil
# End:
......@@ -2,9 +2,8 @@
<property name="context">{/doc/acs-messaging {Messaging}} {ACS Messaging Design}</property>
<property name="doc(title)">ACS Messaging Design</property>
<master>
<body>
<h2>ACS Messaging Design</h2>
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
......@@ -49,14 +48,17 @@ implemented as content repository items that are children of the
message), extensible headers (just like the webmail datamodel), and
versioning as provided by the content repository.
<h2>API</h2>
ACS Messaging provides the <code>acs_messages_all</code> view as
ACS Messaging provides the <code>acs_messages_all</code>
view as
the primary mechanism for message queries.
<blockquote><pre><code>create or replace view acs_messages_all as
select m.message_id, m.reply_to, o.context_id, r.title, r.publish_date,
r.mime_type, r.content, o.creation_user
...
</code></pre></blockquote>
ACS Messaging provides the PL/SQL function acs_message.post to add
new messages.
<hr><address>akk@arsdigita.com</address>
</body>
<hr>
<address>akk\@arsdigita.com</address>
<property name="context">{/doc/acs-messaging {Messaging}} {ACS Messaging Docs}</property>
<property name="doc(title)">ACS Messaging Docs</property>
<property name="context">{/doc/acs-messaging {Messaging}} {ACS Messaging Documentation}</property>
<property name="doc(title)">ACS Messaging Documentation</property>
<master>
<body>
<h1>ACS Messaging Docs</h1><ul>
<li><a href="requirements">requirements</a></li><li><a href="design">design</a></li>
</ul><hr><address><a href="mailto:akk@arsdigita.com">Anukul
Kapoor</a></address><!-- Created: Sat Sep 30 16:42:40 EDT 2000 --><!-- hhmts start -->
Last modified: Sat Sep 30 17:45:40 EDT 2000 <!-- hhmts end -->
</body>
<h1>ACS Messaging Documentation</h1>
<h2>Engineering Documentation</h2>
<ul>
<li><a href="requirements">Requirements</a></li><li><a href="design">Design</a></li>
</ul>
<h2>Release Notes</h2>
<p>Please file bugs in the <a href="http://openacs.org/bugtracker/openacs/">Bug Tracker</a>.</p>
<hr>
<address><a href="mailto:akk\@arsdigita.com">Anukul
Kapoor</a></address>
<!-- Created: Sat Sep 30 16:42:40 EDT 2000 --><!-- hhmts start -->Last modified: Fri Aug 21 11:50:15 CEST 2015
<!-- hhmts end -->
\ No newline at end of file
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>ACS Messaging Docs</title>
<title>ACS Messaging Documentation</title>
</head>
<body>
<h1>ACS Messaging Docs</h1>
<body>
<h1>ACS Messaging Documentation</h1>
<h2>Engineering Documentation</h2>
<ul>
<li><a href="requirements">requirements</a>
<li><a href="design">design</a>
<li><a href="requirements">Requirements</a>
<li><a href="design">Design</a>
</ul>
<h2>Release Notes</h2>
<p>Please file bugs in the <a href="http://openacs.org/bugtracker/openacs/">Bug Tracker</a>.</p>
<hr>
<address><a href="mailto:akk@arsdigita.com">Anukul Kapoor</a></address>
<!-- Created: Sat Sep 30 16:42:40 EDT 2000 -->
<!-- hhmts start -->
Last modified: Sat Sep 30 17:45:40 EDT 2000
<!-- hhmts end -->
<!-- hhmts start -->Last modified: Fri Aug 21 11:50:15 CEST 2015 <!-- hhmts end -->
</body>
</html>
......@@ -2,93 +2,139 @@
<property name="context">{/doc/acs-messaging {Messaging}} {ACS Messaging Requirements}</property>
<property name="doc(title)">ACS Messaging Requirements</property>
<master>
<body>
<h1>ACS Messaging Requirements</h1>
by <a href="mailto:akk@arsdigita.com">Anukul Kapoor</a> and
<a href="mailto:akk@arsdigita.com">Pete Su</a><i>This is only a DRAFT</i><h3>I. Introduction</h3><p>In ACS 3.x, each messaging application (e.g. bboard, general
by <a href="mailto:akk\@arsdigita.com">Anukul Kapoor</a>
and
<a href="mailto:akk\@arsdigita.com">Pete Su</a>
<i>This is only a DRAFT</i>
<h3>I. Introduction</h3>
<p>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:</p><ul>
service provides the following common mechanisms:</p>
<ul>
<li>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.</li><li>Storage of message objects.</li><li>Central support for attachments, threading, and search.</li><li>Mechanisms for sending and receiving message objects as
e-mail.</li>
</ul><h3>II. Vision Statement</h3><p>Messaging applications constitute some of the most useful forms
</ul>
<h3>II. Vision Statement</h3>
<p>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.</p><h3>III. System/Application Overview</h3><p>The ACS Messaging package defines a data model and API for the
single centralized facility.</p>
<h3>III. System/Application Overview</h3>
<p>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.</p><p>The package consists of the following components:</p><ul>
constraints on client applications.</p>
<p>The package consists of the following components:</p>
<ul>
<li>A data model for representing and storing messages.</li><li>A data model for representing and storing attachments to
messages.</li><li>A mechanism for sending messages as e-mail.</li><li>A mechanism for integrating the message store into site wide
search.</li>
</ul><h3>IV. Use-cases and User Scenarios</h3><p>ACS Messaging is generally not used directly by users, so there
</ul>
<h3>IV. Use-cases and User Scenarios</h3>
<p>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.</p><p>We scenarios that we should consider are the kinds of
right now.</p>
<p>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.</p><p>The following applications in ACS 3.x could have been
implemented using this package:</p><ul>
model and API.</p>
<p>The following applications in ACS 3.x could have been
implemented using this package:</p>
<ul>
<li>BBoard</li><li>Webmail</li><li>General Comments</li><li>Spam</li><li>Various parts of the ticket tracker.</li>
</ul><p>Each of these applications requires a message store and each
</ul>
<p>Each of these applications requires a message store and each
defines it's own high level organization for messages whithin that
store.</p><ul>
store.</p>
<ul>
<li>Bboard organizes messages into forums and categories and
threads. It also allows users to send and reply to messages via
e-mail.</li><li>Webmail organizes messages into mail folders.</li><li>General comments attaches messages to objects representing
static or other content.</li><li>Spam queues messages and sends them to groups of people as
e-mail.</li>
</ul><p>The main requirement of the ACS Messages package is to support
</ul>
<p>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:</p><ul>
of common functionality:</p>
<ul>
<li>Reply chaining and threading.</li><li>Messages with attachments of various types.</li><li>Representing messages as multipart MIME e-mail.</li><li>Queuing and sending messages as e-mail.</li>
</ul><h3>V. Related Links</h3><ul><li><a href="design">Design Document</a></li></ul><h3>VI.A Requirements: Datamodel</h3><p><strong>10.0 Message Store</strong></p><p>ACS Messages should provide a single store for objects
representing messages.</p><p><strong>20.0 Message Content</strong></p><p>A message should have a primary content body consisting of a
</ul>
<h3>V. Related Links</h3>
<ul><li><a href="design">Design Document</a></li></ul>
<h3>VI.A Requirements: Datamodel</h3>
<p><strong>10.0 Message Store</strong></p>
<p>ACS Messages should provide a single store for objects
representing messages.</p>
<p><strong>20.0 Message Content</strong></p>
<p>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.</p><p><strong>30.0 Attachments</strong></p><p>Messages may be composed of additional attachments. Each
a message.</p>
<p><strong>30.0 Attachments</strong></p>
<p>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.</p><p><strong>40.0 Unique ID</strong></p><p>Messages should have universally unique identifiers to allow
global reference and RFC-822 compliance.</p><p><strong>50.0 Sender</strong></p><p>Messages should be related to the sending party.</p><p><strong>60.0 Threading</strong></p><p>The system model simple message threads, that is chains of
store one or more revisions of each attachment.</p>
<p><strong>40.0 Unique ID</strong></p>
<p>Messages should have universally unique identifiers to allow
global reference and RFC-822 compliance.</p>
<p><strong>50.0 Sender</strong></p>
<p>Messages should be related to the sending party.</p>
<p><strong>60.0 Threading</strong></p>
<p>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.</p><p><strong>70.0 Search</strong></p><p>Messages should be searchable as part of a site wide search.
straightforward way.</p>
<p><strong>70.0 Search</strong></p>
<p>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.</p><h3>VI.B Requirements: API</h3><p><strong>80.0 Messages</strong></p><p>The system should provide the following interfaces for
manipulating messages:</p><blockquote>
site wide search.</p>
<h3>VI.B Requirements: API</h3>
<p><strong>80.0 Messages</strong></p>
<p>The system should provide the following interfaces for
manipulating messages:</p>
<blockquote>
<p><strong>80.10 Creation</strong></p><p>Applications should be able to create new messages objects.</p><p><strong>80.20 Revisions</strong></p><p>Applications should be able to create a new revision of a given
message object.</p><p><strong>80.30 Deletion</strong></p><p>Applications should be able to delete a message and all of its
revisions and attachments. (is this true?).</p><p>
<strong>80.40 Type Checking</strong> Applications should be able
to check whether or not a given object is a message.</p>
</blockquote><p><strong>90.0 Message Attachments</strong></p><p>The system should provide the following interfaces for
manipulating message attachments.</p><blockquote>
</blockquote>
<p><strong>90.0 Message Attachments</strong></p>
<p>The system should provide the following interfaces for
manipulating message attachments.</p>
<blockquote>
<p><strong>90.10 Creation</strong></p><p>Applications should be able to create new message attachments
and connect to their parent object.</p><p><strong>90.20 Revisions</strong></p><p>Applications should be able to create a new revision of a given
attachment.</p><p><strong>90.30 MIME Types</strong></p><p>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.</p>
</blockquote><p><strong>100.0 Messages and E-Mail</strong></p><p>The system should provide the following interfaces for
</blockquote>
<p><strong>100.0 Messages and E-Mail</strong></p>
<p>The system should provide the following interfaces for
integrating with existing E-mail systems. Note that these
requirements only deal with <i>sending</i> mail. Our feeling that a
seperate package should be implemented to deal with
<i>receiving</i> mail that would use ACS Messages for storage of
incoming messages.</p><blockquote>
incoming messages.</p>
<blockquote>
<p><strong>100.10 Sending Single Messages</strong></p><p>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
......@@ -96,7 +142,9 @@ deal with transport failures and so on.</p><p><strong>100.20 Sending MIME Messag
multipart MIME messages.</p><p><strong>100.30 Sending Digests</strong></p><p>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.</p>
</blockquote><h3>VII. Revision History</h3><table cellpadding="2" cellspacing="2" width="90%" bgcolor="#EFEFEF">
</blockquote>
<h3>VII. Revision History</h3>
<table cellpadding="2" cellspacing="2" width="90%" bgcolor="#EFEFEF">
<tr bgcolor="#E0E0E0">
<th width="10%">Document Revision #</th><th width="50%">Action Taken, Notes</th><th>When?</th><th>By Whom?</th>
</tr><tr>
......@@ -104,7 +152,9 @@ bboard thread could be sent to a user as a digest.</p>
</tr><tr>
<td>0.2</td><td>Edited and extended for more general data model</td><td>11/07/2000</td><td>Pete Su</td>
</tr>
</table><hr><address><a href="mailto:kapoor@maya.com"></a></address>
Last modified: $Id: requirements.html,v 1.1.1.1 2001/03/13 22:59:26
</table>
<hr>
<address><a href="mailto:kapoor\@maya.com"></a></address>
Last modified: $&zwnj;Id: requirements.html,v 1.1.1.1 2001/03/13 22:59:26
ben Exp $
</body>
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment