Finding extra help is always nice, but I worry about expanding our scope early on by including many projects' objectives.
No interest in expanding scope. I don't see that the scope has changed since we started talking about it last year, and I don't believe that it would have any impact on the event level of the code. The place it would have any impact would be on the addition of new methods to support pushing buffers rather than just reading from a stream.
Just flagging the issue that if we bring in other developers from other projects /their/ scope may be different than ours. I know our scope is pretty constant and straight-forward.
Caching might be nice, but I would think to cache the headers rather than the body.
The way dbfile works is that the headers are in the db, the larger body is in the file system, and we have a MimeMessageSource that spans them on demand. The blog is still read into a ByteArrayInputStream, but it contains only the headers. My thought was to add an option to cache the blog in the file system, largely by leveraging the existing support for dbfile.
Sure, you could also (after loading from the database), write the headers to the cache, or well, not sure how this works with the saxmime approach.
Ideally the caching system is transparent and each installation could cache differently.
Naw, I think we should hardcode everything. ;-)
Fair enough. I thought it'd be a nice to have, but you're right, it really doesn't need to be /that/ flexible when we release it.
-- 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]
