openerp-expert-framework team mailing list archive

["P. Christeas" <xrg@xxxxxxxxx>]

Following some conversation with hmo, reading the code of mail_gateway, 
poweremail and the presentation of 'dm', I would like to propose a generalized 
approach to messaging support in the OpenERP classes.

The goal is to separate the code that wants to convey a message to the users 
or partners from the implementation of messaging (emails so far). This will
both reduce the dependency to modules, and also allow for some interesting 
extensions (like SMS/telephone calls).

The thoughts, below, are surely draft, at a preliminary stage. Notice that I 
have intentionally kept the number of columns low, just the essential ones. 
Any extra functionality should better be implemented by derived classes.

Please, your comments, again.
Regards.
 

Message: It is a fundamental piece of communication, like a network packet.
 - Timestamp
 - From (single, string)
 - To (single, string)
 - state
 - Carrier_id (conveys much info about nature of msg)
 - msg_id (string, identifier according to carrier)
 c: unique(carrier_id, msg_id)
 - Subject (string, title)
 - Body (text representation of information, summary)
 Optional fields (to be discussed):
 + Extra_addrs (list of (kind, address, aid), for cc, bcc, additional to's etc.)
 + From_aid  res.partner.address for "From" (optional)
 + To_aid  res.partner.address for "To" (optional)
 + Folder_id: a reference to a logical folder where the message belongs

Carrier: It is a method of communication, like res.request, a telephone system
or a set of email gateways (POP3 + SMTP).
 - Type: [ email, phone, smail, request, sms, ... ]
 - Name
 \ + all other details in derived classes
 
Thread: A chain of messages, of any type.
 - Name
 - message_ids: list of messages that belong to thread
 - ir.model, res_id : Attach thread to some specific resource (eg. CRM thread)

Folder: A container of messages, like Inbox, Outbox etc. 
(taken from Poweremail) 
  A folder is an optional pointer, merely to match the traditional method
of storing messages in folders (and optionally help classify them). It is
another "dimension" of categorizing the messages. Multiple types of 
messages in the same folder are allowed by the API, but could be limited
by the carrier or folder implementations.

It should be the carrier object that creates instances of messages, but 
through a standardized API. Carrier could also have functions for replying,
forwarding or redirecting (copying) a message to a new destination.

The msg_id is presented in all classes, although its contents will largely
depend on the carrier type and implementation. This common field helps
manipulate any messages, without losing their sense of id.

Consider the case of anychronous (eg background) sending of messages: the
carrier just creates a message instance, and the python code returns. 
Then, another thread (or even another process) will discover that the
message is pending, and try to process/deliver it. In that second stage,
the processing of addresses may be done. That's why from, to, etc. have
both a reference to res.partner.address and a string representation.

Attachment: messaging-api.svg
Description: image/svg