The reason I mentioned Jakarta Commons was because of a thread back in March*. There has been some interest in Multipart MIME there. But I think it might be best to develop it here, and then consider moving it to Commons. Frankly, I don't want to be held to a coordinated schedule with Commons Codec. But I would invite Mark** to work with us on the code, if he were still interested.
I would prefer to develop it here since we have a very tangible problem to solve.
That is similar to why Alex Karasulu started the streaming codec work in Directory. And it might be worth looking at Alex's streaming codec, and adopting is a common interface for moving the data into the package.
Finding extra help is always nice, but I worry about expanding our scope early on by including many projects' objectives.
Database streaming is already an issue, as I noted a couple of weeks back, because it forces us to load the entire message into memory when using the db protocol. Not streaming over JDBC isn't entirely bad, since connections are a limited resource even when streaming is well supported. I've been wondering if the db protocol might benefit from an on-the-fly dbfile-like approach where the body is cached. That could significantly increase performance when using the db protocol for spooling, and reduce the footprint for POP3/IMAP.
Caching might be nice, but I would think to cache the headers rather than the body. But it's easy enough to change that and test what's faster. Ideally the caching system is transparent and each installation could cache differently.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
