james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oki DZ <ok...@pindad.com>
Subject Re: cvs commit: jakarta-james/src/conf spool.properties
Date Fri, 03 Aug 2001 01:38:13 GMT
On Thu, 2 Aug 2001, Charles Benett wrote:
> I think Serge was talking about my suggestion that you might want e.g.
> spool, spam and error mesages in a different db (which may or may not
> mean a different db server) from the POP3 inboxes.

I see.
> I'd have thought it was very likely that people might have their Users
> in a different db or db server from their mail.

I think the more features James has, the better. Problem is, how easy is
it in configuring it. If it's pretty easy, then it would be all right.
> I haven't tried it, but it should be as simple as ./build.sh
> -Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true

I did that when I tried to use Serge's noparse-mimemessage. But that's
the command for getting the appropriate files in the build directory (ie: 
not for submission).

As I understand it, the proposal directories contain the source which
would eventually become included in the distribution. I was thinking about
a "contrib" directory, where the source files would be in there and be
used according to the user's needs. For example, mailets. I believe that
there would be more mailets being written (by non-committers), and I don't
think that putting them all in the .sar file would be useful. So, the
contrib directory would be a nice place to put them; and then have the
mailets included by executing the build.sh command with the appropriate

That's just about semantics (different rendering of the word "proposal"),
though; if what is meant with "proposal" also represent what I meant with
the "contrib" above, then there's no reason in creating a new directory. 
We can use what's already available. But... I don't think that creating a
"contrib" directory would be costly. Besides, it would make ones more
relaxed in submitting codes; they don't have to be committers. 

Well, I believe that I still have something missing; if you submit source
files to the CVS, should the package names have "org.apache" in them? I
guess not. If it is, then it's too restrictive. If the restriction should
be in place, then the "contrib" might be an acceptable solution; so that
ones could submit codes with any package names they like. And also, the
submitted codes don't have to be working out of the box; eg: a submitter
might upload a mail repository that expects totally different database
schema for the repository table. 

The mail repository may not be needed by most of the James users, but
somebody might badly need it given the same environment where James is
expected to be run. Think about a mail repository that implements direct
calls to MySQL client libraries via JNI (Java Native Interface) to speed
things up. I believe such repository doesn't belong to the main branch in
the CVS; the code wouldn't be that portable, tightly tied to the operating
system where the repository should be run. But it would be really nice if
the code is accessible by the James users at large, and it would need a
nice place where to put it. 
> BTW, what are you working on?  

MySQLMailRepository, MySQLSpoolRepository, and UsersMySQLRepository that
implement Turbine's db connection pooling. The spool repository implements
a global cache that temporarily stores the list of the messages that
resides in the spool; so that when the spool repository's accept() method
gets invoked (after the first invocation), there would be no additional
SQL query sent to the db server. This would make the spool works faster I
believe, even if the db pooling is already there.

Also some fix up in the MimeMessageJDBCSource (well, I created
MimeMessageMySQLSource class); I reimplemented (by overriding) the
getSize() method using an SQL query to the server.

>If they are not too long, you can email
> the source to the list and someone can commit it for you. Alternatively,
> you can email it to a committer (e.g. me, Serge, etc.) and ask them to.

I see. This is much more simpler. I'm going to have some fix ups on the
mail repository; currently, I have all the prepared statements created
once in the initialize() method, inadvertently forgetting that the
instance of the mail spool is only one but more than one thread of spool
manager may access the spool in a given time. 


To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message