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

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...

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?

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.
<p>
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.

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.