On Mon, Aug 1, 2005, Brandon Mercer <[EMAIL PROTECTED]> said: > Kevin Baker wrote: > >>It is my understanding that the biggest issue with IMAP >>web interfaces is connection handling. Basically there is >>no connection pool for IMAP on most, at least PHP, web >>clients. >> >>This can be handled easily by implementing something like >>Perdition IMAP Proxy that has its own connection handling, >>in addition to other great scalability features, that will >>help significantly with this IMAP *Client* issue. >> >>As pointed out by Mike, I'm pretty sure it is not a >>protocol or server issue... it is really a client >>connection handling issue. >> >> > I have just done some "testing" and I can much better attack the > information in the database through my own connections rather than > IMAP. Case closed. :-) I'll be writing my own API in both java and C > to your program, it will be release under a BSD style license. It will > account for changes in the database tables should there be any. If > anyone is interested please let me know. > Brandon
You're welcome to go this route, and indeed it has already been travelled by webDBmail, and it works fine. The deal is that the 2.1 series is development. It would be a burden on the development effort to have a live library out there that people want us to remain tied to and not make any database changes. But I figure it'll take you a while to write your library, and at some point we'll have frozen the database and have stable releases of DBMail on that. So you'll probably be safe. But we're also going to be writing a libDBMail to abstract the interface to the database so that *if we do need to change a stable database* we can safely do it without third parties screaming at us. So, from a certain point of view, you're basically writing libDBMail-Java. Aaron
