Forum OpenACS Q&A: Re: RFC: New system for incoming and outgoing email

Collapse
Posted by Mat Kovach on
Jeff,

Hey, it made a lot of since to me.

I should clarify.

The seperate will be something like:

-, +, |, etc.  Now that you have raised the question I think a simple list of possible values that can be choosen would be better.

The TAG would be something else.  For notificatitons you could set that as 'notifications'.  I do plan on creating a function to create proper strings.  That function will give you the options of also using the user_id in the string OR the email address.  Yes using the email address on OpenACS does cause the problem.

The unique tag COULD be the package name, it would be something that is defined.

Maybe an example might help:

Say we have a server where '+' is the seperator and the domain is mek.cc.  You create a few forums and give each one a unique tag, say qanda and development (this would be added to the forum administration).

This would create the following email addresses that could be used:

mailto:qanda@mek.cc
mailto:qanda+user_id+message_id@mek.cc
mailto:developer@mek.cc
mailto:developer+user_id+message_id@mek.cc

The incoming processor would do the following:

Look at the email and parse it, basically looking
for the <identifier>@mek.cc or <identifier+stuff>@mek.cc.
Once it has the indentifier it will send the message to the proper area.  There the forum package could say:

Okay qanda is for forum Q and A.  If the message has
no extra stuff we create a new forum thread with
this subject but we check the From address to make sure
the user is a valid user.  If the message has extra stuff,
we make sure the user_id is valid and post as based on the message id.  But this part would be up to the package
maintainer.

Does this clear things up a bit?

Collapse
Posted by Jeff Davis on
I guess given this example I am still sort of stuck knowing how the unique tag is mapped to a service contract. Above you say "Okay qanda is for forum Q and A." but I don't see anything in the design that lets you tell that. Especially since qanda maps to something below a package (a forum). Is there a mapping table that says:
unique tag   package   extra stuff
qanda        forums    {forum_id 200}
and you invoke a "forums" service contract for forums with the "extra stuff" passed in to indicate which forum it is?

Or do you invoke a service contract implementation "qanda" which has the forum_id either curried in or require that forums maintain it's own table to map unique tag to forum_id and bind a service contract per unique tag?

Collapse
Posted by Malte Sussdorff on
In my opinion the unique tag should be named after the service contract that is executed in it's behalf. In the case of forums it should be called "forums" and the additional information would contain items like "forum_id", "parent_id" (if in reply to something). Alternatively it would be "bounce" for the bounce management service contract. You should also keep in mind that you want to support multiple packages of one package type, so you need to pass on the package_id as well.

In addition to the default naming (e.g. forums, bounce, blogger), you should have a mechanism to define named special cases. E.g. you will map the "qanda" unique tag to the "forums" service contract with prefilled value for forum_id. For obvious reason, the user interface needs to be well thought through and we should *NOT* have to create the named special cases by going into the code.

Some more remarks based on previous challanges:

How do you make sure that all mails belonging to OpenACS are delivered to the mail-dir, but not the other mails, if you do not know which packages are installed? Wouldn't it make sense to have a prefix like "oacs" for each email address (incoming and outgoing) so that the MTA can differentiate between mailto:malte@sussdorff.de and mailto:oacs-malte@sussdorff.de, where the later goes to the "malte" package at the same domain ?

This is especially true if you want to allow easy postings to forums. The Email should be easy to remember (e.g. mailto:Forum-openacs_dev@openacs.org). Alternatively you can configure your MTA to try all other delivery methods first and only if all failed, store the Email in the maildir for OpenACS.

Furthermore, make sure you do not interfere between multiple installations of your mail-package on the same site. Therefore the system name (from your aolserver config) should make it into the mail scanning as well, to prevent server1 reading and storing mails destined for server2.