Forum OpenACS Development: acs-mail, acs-messaging et al.

Collapse
1: acs-mail, acs-messaging et al.
Posted by Jon Griffin on 05/07/01 06:10 PM
I have been looking hard at acs-mail,acs-messaging and etc. See http://jongriffin.com/sta tic/openacs/

I have some thoughts and questions I would like to bring forward as well as some ideas on where to go. I really don't think a straight port is the thing to do so here goes:

  • Do we really have to derive a mail package from acs-object?
  • acs-messaging could be left as is and just stripped of its mail handling parts. I am not sure in practice that using content repository is needed, but to get rid of that is a complete rewrite and remodel.
  • I am really worried (again) about scalability. I am not sure how how optimized Content Repository is and even so that goes through acs- object at some point. Think lots of querys.
  • acs-mail, if it is not going to use acs-object, could be a lot lighter weight if the query was done in tcl instead of pl/sql, but I don't really have a preference. I am thinking more of portability here.
My initial thought is to make acs-mail and acs-messaging seperate. Of course, I would have to eliminate all the mail dependent code from acs-messaging.

acs-notifications can be stubbed out in acs-mail and the aggregation added at a later date.

In short, make acs-mail a mail only package, eliminate acs- notifications and move its public interface into acs-mail, and delete any mail related code from acs-messaging and leave it as a seperate package. A side effect of this is that a package like bboard will need to call acs-mail on its own if it needs/wants to send mail. I think this is cleaner in any case.

Collapse
2: Response to acs-mail, acs-messaging et al. (response to 1)
Posted by Edmund Lian on 05/07/01 07:24 PM
One requirement I'd add is that these packages should be independent of the MTA used. While qmail is an aD favorite, I think being able to support excellent alternatives like postfix is a must...
Collapse
3: Response to acs-mail, acs-messaging et al. (response to 1)
Posted by Jonathan Ellis on 05/08/01 05:21 PM
I'm a postfix fan, but I don't think it's reasonable to say, "be mailer independant."  I'd settle for, "realize someone's probably going to want to use postfix or even sendmail and try to avoid depending on qmail's idiosyncracies where possible."  There just isn't a totally portable way to do some things.
Collapse
4: Response to acs-mail, acs-messaging et al. (response to 1)
Posted by Jerry Asher on 05/08/01 06:01 PM
IIRC, two problems with the 4.0 acs-messaging/acs-notifications were: one, every message every created was just left in the db there was no cleanup or maintenance of the db, and two, the api was impractical from the tcl side: mail had to be addressed to user_ids rendering it impossible to send email to anything not a member of the site.

In fact, with aDACS 4 design, it went beyond impractical. aDACS 4 modules were never designed as a whole system. So that in the aDACS 4 Tcl kernel parameters, we have the strings for system administrator email addresses, etc., and no standard/official/approved/designed way to associate *the system administrator* with an actual user_id (http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000XpY), and then the notifications package stumbled along requiring user_ids for message recipients:

Say I want my ad_tripwire module to use the ACS Notifications system to notify the web admin that he just got hacked and gave up all his credit card records. ACS Notifications takes a userid, not an email address. How do we get the Admin's email address or his userid?
Oh man, Jon, I hope you will clarify this.
Collapse
5: Response to acs-mail, acs-messaging et al. (response to 1)
Posted by Don Baccus on 05/08/01 07:47 PM
Jerry ... if you have a moment, would you add this to the SDM for the module?  Jon's doing a straight-across port first so Henry can get on with bboard, but clearly this is something that *must* be fixed down the line.  I trust us to read the SDM looking for trouble reports more than I do for us to scour old forum threads, though Jon may work on rationalizing this stuff so soon as to make it irrelevant.
Collapse
6: Response to acs-mail, acs-messaging et al. (response to 1)
Posted by Jerry Asher on 05/08/01 07:53 PM
I will put it in the SDM, and that's another module/substrate after oACS 4 gets out: the ACS <-> ACS scraping layer (um, I mean import/export/replication layer).  Those comments (and more!) have been entered in the aD SDM (lot that did for us, eh?)