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

Collapse
Posted by Don Baccus on
acs-mail, as written today, does not scale.  That was the main reason for OF writing acs-mail-lite.  It creates all sorts of objects to contain MIME attachments and stuff (I think, I haven't looked at this in a long time) and overall the implementation just seemed very inefficient.

And it was only used in a few places.

While I'm sympathetic to the goal of backwards compatibility, do we really need to keep the worst of the worst available for use forever and forever when we know the code really sucks and is fubar'd beyond any reasonable hope of repair?

How devoted are you to this concept, Tom?  If we uncover a security hole that requires an API change to fix, should we leave the hole open because of slavish devotion to the principle of maintaining API compatibility forever?

I wouldn't see any harm in deprecating acs-mail in favor of an acs-mail-lite that has all the features we need but is more efficient as long as we give people ample notice that it's going away.  What is ample notice, then?  Six months?  A year?

Collapse
Posted by Jeff Davis on

One thing I think is important to do is make clear which packages are no longer actively developed and which have been superceded by another package. Moving them to obsolete-packages seems to be the best way to do that. bboard is a good example. People were still using it on new installs even though it had a host of problems mostly because it wasn't clear that forums was the prefered package.

In any case, I had a look through the code and here are some observations:

  • acs_mail_lite::with_finally should go somewhere else (probably along side with_catch in acs-tcl utilities-procs.tcl)
  • it needs upgrade scripts for existing installs (since it changes the datatype of to_addr to text/clob, and adds some columns and renames some constraints
  • I dislike that it renames existing constraints since its certainly possible that some people code might check for the contraint name when an insert or update fails.
  • the code has tabs rather than spaces (although since we do not have any coding standards I guess thats not a fair criticism).

I agree with Don that it should be a 5.1 thing though.