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 Thu, 02 Aug 2001 04:33:58 GMT
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

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

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

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

> We can always make the code more readable later... as long as it works
> well and has a good design. 

Sure, works well, faster, and has a good design.


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

View raw message