Index: openacs-4/packages/acs-messaging/www/doc/design.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-messaging/www/doc/design.adp,v diff -u -r1.2 -r1.3 --- openacs-4/packages/acs-messaging/www/doc/design.adp 27 Oct 2014 16:39:42 -0000 1.2 +++ openacs-4/packages/acs-messaging/www/doc/design.adp 7 Aug 2017 23:47:57 -0000 1.3 @@ -1,10 +1,9 @@ -{/doc/acs-messaging {Messaging}} {ACS Messaging Design} +{/doc/acs-messaging {ACS Messaging}} {ACS Messaging Design} ACS Messaging Design - -

ACS Messaging Design

+ 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 @@ -29,34 +28,38 @@ Another example: if we built the IMAP server functionality 3.4 webmail provides against acs-messaging, then bboard forums, pages of comments, and webmail folders could be viewed uniformly through -your email client. The IMAP mapping isn't quite trivial, but you -can see the idea.To reiterate, if applications are storing the same -sort of data (a text-ish messages with optional attachments and -replies), they should store them the same way. Then code from +your email client. The IMAP mapping isn't quite trivial, but +you can see the idea.To reiterate, if applications are storing the +same sort of data (a text-ish messages with optional attachments +and replies), they should store them the same way. Then code from particular applications can possibly be refactored into generic -functionality.spam/general alerts/etc isn't meant to be replaced by -ACS Messaging, at least not with what is there currently. Currently -it is just a store; but we intend it to be the canonical store for -messages that need to be stored in the database. If messages are -automatically generated from other user objects, they might need to -be queue'd up or archived in the RDBMS. If so this should be done -in the acs-messaging tables. We can implement the generic incoming -email system by stashing messages in acs-messaging, then -dispatching the message id to package specific code for -processing.Currently (11/2000), ACS Messaging is very slim; it just -supports bboard. We intend to add attachments (most likely -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. +functionality.spam/general alerts/etc isn't meant to be +replaced by ACS Messaging, at least not with what is there +currently. Currently it is just a store; but we intend it to be the +canonical store for messages that need to be stored in the +database. If messages are automatically generated from other user +objects, they might need to be queue'd up or archived in the +RDBMS. If so this should be done in the acs-messaging tables. We +can implement the generic incoming email system by stashing +messages in acs-messaging, then dispatching the message id to +package specific code for processing.Currently (11/2000), ACS +Messaging is very slim; it just supports bboard. We intend to add +attachments (most likely 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.

API

-ACS Messaging provides the acs_messages_all view as + +ACS Messaging provides the acs_messages_all + view as the primary mechanism for message queries. 
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
     ...
+ ACS Messaging provides the PL/SQL function acs_message.post to add new messages. -
akk@arsdigita.com
- +
+
akk\@arsdigita.com