Forum OpenACS Development: acs-mail uses acs-content, should it?

Posted by Vinod Kurup on
Hi all,

I've been helping Jon Griffin port acs-mail and I was trying to merge the functionality that's in acs-notifications into acs-mail. I've run into a problem, though. acs-mail stores content in acs-content (not acs-content-repository). What is acs-content? It's supposed to be a lightweight version of the CR. Like the old aD CR, it stores everything in a blob. When acs-content was ported, the only change was to convert the 'content' column from a blob to an integer. I suppose this was done to use Don's lob hack (which I haven't used before, so I don't completely understand). But the .tcl code in acs-mail still depends on 'content' being a blob. And I can't figure out how I'm supposed to call acs_content__new:

create function acs_content__new (integer,varchar,varchar,char,integer) returns integer as ' declare new__content_id alias for $1; new__mime_type alias for $2; new__nls_language alias for $3; new__searchable_p alias for $4; new__content alias for $5; ...
I did a quick grep through the packages and it seems that acs-mail is the only package that uses acs-content. So it seems that there are a few options:
  1. Change acs-mail to use the CR
  2. Change acs-content to accept a text column (which seems kinda like duplicating the CR functionality)
  3. Some other intelligent thing that I'm overlooking
I'm leaning towards #1, but I know that acs-mail was meant to use acs-content and I suppose there were good reasons for this. (lower overhead, easier garbage collection?). So, I guess I'm looking for a little advice on how to proceed...
Posted by Jon Griffin on
I would think #1 would be best, especially considering the future integration of all the mail/messaging and etc.
Posted by Pascal Scheffers on
I agree with option #1. Everything in the CR seems to be the way to go. acs-messaging does so, so acs-mail should do it too.

Was there a reason for aD to not use acs-messaging for acs-mail?

Posted by Jon Griffin on
Two different people, two different packages (actually 3 if you count notifications).

I am re-writing the two to become one package after our initial release.

Posted by Don Baccus on
Yeah, #1 sounds good.  If you're interested in the PG BLOB stuff (just  for curiousity's sake) the CR makes use of it, and the file lob.sql has the table definitions.  All it does is slice the data into 8KB chunks with a common id and sequence number.  The common id number is what's stored in the LOB column and what's passed to the driver when you stuff content in or grab it out.
So the Nth lob is stored as tuples in the from (N, 1, data), (N, 2, data), etc.  The driver does a "select data from lob where lob_id = :lob_id order by segment_sequence", then pastes the segments into one big piece.
<p>That's all there is to it for a character large object.  Binary large objects are uuencoded.
<p>Of course, as of 7.1 the text type is unbounded and character large  objects are no longer needed.  And 7.2 will have a real binary large object type (storing them in 7.1 isn't a problem, I/O is the problem).
<p>So eventually the driver hack will go away entirely.
Posted by Richard Li on
After implementing bboard on top of acs-messaging, we realized that there were some performance/scalability problems with the way we were doing things. One area that hurt performance was the use of the CR; we also felt that we didn't need all the functions of the CR. Thus, we implemented acs-mail as a replacement for acs-messaging (this is discussed in the release notes somewhere, I believe). We did not remove acs-messaging so as not to break backwards-compatibility with existing applications that used acs-messaging.
Posted by Don Baccus on
Can you be more specific about performance problems with the CR?  If it's too slow for bboards it will be too slow for many things, so I think we'll want to at least take a shot at seeing if performance can be improved to an acceptible level.