Forum OpenACS Development: Re: RFC: New OpenACS Mail Procedures
An issue that is not that easy to answer in my opinion is the question of the format of the message body. The old acs-mail package is capable of sending a mail either in text/plain or in text/html, or in multipart/alternative, which contains both a text and a html version and lets the receiving mail program decide which version to display. Also I think it was capable of sending aolhtml, which is a subset of html and a different mime-type. Maybe it is even capable of including any mime type in a multipart/mixed message. I wonder what of this functionality if at all we want to retain, and suggest to limit ourselves to a message body content type of text and html for simplicitys sake. We could then include a body_text and body_html field in the queue table, sending out whichever is filled or multipart/alternative if both are not NULL.
Unless someone comes up with a good reason why message body in a mime-type different than text/plain or text/html would make sense one time. (text/xml? what for?)
Limiting the message body that way would make the datamodel a lot simpler than that of the current acs-mail package. Which I don't fully understand to be honest.
Another functionality of the old acs-mail package that I suggest to drop is that it tries to minimize database storage by separating message bodies from the metadata and possibly reusing message bodies, in case the same message was sent to multiple recipients. This only makes sense when the message is intended to be stored for longer as reference (which no package uses right now I think), not when it is meant to be sent out quickly and removed from the queue anyway.
It would be good to add to the requirements that we should have a service contract based send framework that supports pluggable transport mechanisms (ns_sendmail, qmail-inject, ...).
Why does your mek::send procedure take a package_id and what does it do with it? Do you plan to keep the entries generated in the queue after a successful send in general or would you agree that they only stay in the queue as short as necessary?
Should the rfc Message-ID really be unique? What about a bulkmail process that sends out a mass mailing which is slightly personalised, e.g. by replacing the name of the recipient in the body. Wouldn't one in this case want to have the possibility to send out each of these messages with the same Message-Id? This could be achieved if mek::generate_message_id would be publicly callable and mek::send would optionally accept -rfc_message_id as parameter. I can't think of another example where this would be useful right now, but somehow I have the feeling that we should support non-unique rfc Message-IDs.
On a minor side-note I suggest to add .oacs to the rfc message-id as implemented in the modified acs-mail-lite I sent you, which makes it immediately clear to someone looking at the headers that the message was generated by openacs.
