Serge Knystautas <[EMAIL PROTECTED]> Wrote: >Charles, >- I've written the JDBCMailRepository to store message bodies in the file >system. Even after all this work to not parse messages, a large message (a >meg or more) would still bring my JDBC driver to a crawl. Now, the >JDBCMailRepository will store all delivery information and the message's >headers to the database, and the message body separately to the file system. >It's hopefully written in such a way that you could turn this off and on, as >it should already read a message that is entirely stored in the database and >so you'd just have to change how it saves messages. This sounds a little dodgy, I can see why you would want to do this, but don't forget the scenario whereby several machines are all accessing a seperate db machine/cluster the filesystem model would breakdown there. One of my overiding aims is to see James feeding into, and reading from, a db which can also be accessed by applications (servlets probably, but not necessarily) which would probably be accessing a common db from a cluster of app/web servers. I would like to see webapps given mail access by dumping messages into the repository, then have James deal with transporting them in any way it sees fit. Much like pipeing messages to sendmail. Likewise I'd like to see, for instance, other applications have the ability to search and retireve messages from the db based on message content. I'm using webmail to write this message, I currently have 96 messages in my mailbox, how nice to be able filter/search and sort them on-line like I do when I'm using outlook. If the message body is not in the db this wouldn't be as trivial a task as generating SQL.
test test test
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
