james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Benett <char...@benett1.demon.co.uk>
Subject Re: cvs commit: jakarta-james/src/conf spool.properties
Date Thu, 02 Aug 2001 08:54:29 GMT
Oki DZ wrote:
> On Wed, 1 Aug 2001, Serge Knystautas wrote:
> > I like the idea about the size SQL query.  However, there isn't a standard
> > SQL function to do this.  MS SQL uses "datalength(message_body)", while
> > mysql (I'm assuming from your example) uses "length(message_body)".  This
> > makes it more complicated to use out of the box because the admin would have
> > to configure the SQL for their database vendor.  I could always make the SQL
> > statement optional and add more if's to the code. :)
> You already have the SQL statements in a properties file (CVS James).  And
> you could supply James with the appropriate properties file for each db
> supported by James. IMO, it's not a problem, not a problem at all. All the
> admin needs is to rename one of the supplied properties file to the right
> one. Besides, it makes POP's LIST _tons_ faster. Yes, I have implemented
> it by rewriting JDBCMail/SpoolRepository (and surely, with constantly
> looking at your JDBCMail/SpoolRepository during the rewrite :-)
> > As for performance, I don't think James has much to do with the slowness (I
> > think it's the JDBC driver).  Can you test using the mysql JDBC connection
> > to retrieve the large message?
> Nice idea; I'll try that sometime. (But again, as always, complaining in
> this list is a lot easier and faster :-)
> >Comparing it against the native tool isn't a
> > fair comparison.
> It might not be fair, but the time difference was so big, and it made me
> really wonder. And I think getting James speeding up is one of the right
> objectives, right? The native tool could be used as a time reference.
> > I agree it's starting to look a bit like [language you don't speak].  The
> +1
> (just try things out)
> > good thing though is that I think it's about as complicated as it can be.
> > The only other feature I've heard requested is to store the message in
> > another database.
> -1
> (is this the right dev-speak?)
> You mean like the UsersRepository in a database server and MailRepository
> in another one? I see no point in that.

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'd have thought it was very likely that people might have their Users
in a different db or db server from their mail.

> >While this class is getting a bit tough to read, I think
> > it'd be easier to maintain this one class than to start branching and making
> > near duplicate versions of the code (for the DB and DB/file versions).
> Nice idea; and I like the way build.xml's "proposals" works. BTW, can I
> have mine also? ie: by simply have a new directory (and have some codes
> inside) and then execute the right command for ant? I already have some
> source files, but I put it directly under .jakarta-james/src/java; it's
> the wrong way, I believe. I've been dreaming about uploading something to
> the CVS, and the wrong way would make it difficult.

I haven't tried it, but it should be as simple as ./build.sh
-Dproposal.dir="${proposal.base}/okis-proposal" -Dwith.proposal=true

BTW, what are you working on?  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.


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

View raw message