> I would prefer to develop it here since we have a very tangible problem
> to solve.
We're in agreement on both the approach and the reasons.
> 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.
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.
> 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.
> Ideally the caching system is transparent and each installation
> could cache differently.
Naw, I think we should hardcode everything. ;-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
