Forum OpenACS Improvement Proposals (TIPs): Re: Tip #26 (Proposed): Exchange acs-mail-lite

Posted by Lars Pind on
Yes, we'd have to change existing code to use whatever we decide to standardize on.

One of the major differences between acs-mail and acs-mail-lite is that acs-mail handles multipart MIME messages, encoding/decoding each part appropriately based on the content type, etc.

We need this functionality.

Does your acs-mail-lite support this?


Posted by Tilmann Singer on
> why do we have acs-mail and acs-mail-lite in the first place

My guess the only reason is this: Because openforce was under heavy time pressure when they had to deliver dotlrn and didn't want to bother with understanding and potentially having to fix the existing package acs-mail.

Don't know what packages are using acs-mail right now, but if we merge acs-mail-lite into it that would mean that at least we would have to change the calls in all packages that use acs-mail-lite, which is mainly notifications. And maybe some more in dotlrn.

Maybe the merge would also suggest improving / modernizing the acs-mail api which would mean that existing acs-mail calls would need to be modified as well (I'd volunteer for that). Or we can build a compatibility wrapper that maintains the old acs_mail_lite:: and acs_mail calls.

Posted by Malte Sussdorff on
Hi Lars, define *support*. What we do in the mailinglist package is to use a special send function, that handles multipart MIME, encoding/decoding, alternative mails, character sets (okay, maybe I go to far there).  And acs-mail-lite sends it out. So yes, for sure, it does support this ;).

If you want this to be part of the mail system it should not be much of a deal to just copy the function from one scope to another. But here I will stay out and ask Timo to comment on this, as he was heavily working with it and has the in depth knowledge.

Posted by Randy O'Meara on
I just thought I'd reiterate again...


Sorry for raising my voice, but there has to be a better way to migrate to a newer and better mail package than ripping the old one out (moving it to the obsolete packages graveyard) and plunking in a new one with the same name but a different API.

There are folks out there using the current packages and they will not follow along to new releases if it breaks their production code.

Or, maybe I misunderstood what is proposed?

Posted by Tom Jackson on

Randy, I don't think you misunderstood at all.

You know HIV, the virus that causes AIDS, kills its host by constant mutation. Our amazing immune systems kill most of it over and over again, but a little bit that is slightly different remains to grow up again. API changes are like giving HIV to your Open Source project. Amazing, enthusiastic programmers do their best to keep up, but eventually succumb to these tiny changes.

But I'm also reminded of how, when I was a kid, I would find a typewriter or other complex mechanical device. Not having the tools or patience to take it apart, I'd just smash it on the ground and then collect the parts that fell off. Cool!

Posted by Malte Sussdorff on
Sorry to contradict Tom here, but I'm not talking about breaking existing code. If the OCT wants to move my initial proposal of upgrade of acs-mail-lite to a overhaul of the mailsystem, that is up to them. I merely propose to use the contrib version of acs-mail-lite instead of the version that resides in packages, as the contrib version contains quite some *enhancements* that are *not* breaking any existing code.

So maybe we should stick with the *original* TIP and make a decision on this before we talk about changing the whole mailsystem. But again, this is up to the OCT.

One note on the API changes. If I'm not mistaken, mutation is welcome in the world of science, otherwise progress would not happen. What we just have to make sure is that the API does not break existing code (thereby not taking a darwinistic point of view). Which is really easy to accomplish, especially in this case.

Anyway, all I can do  is to mention that there is acs-mail-lite in contrib, that does not break existing code, is compatible to the version in packages and it's up to the OCT to come to a decision whether to use it for OpenACS or not. Anyone wanting to get bouncing and documentation can still take the contrib version after all.