Another lurker popping up in this thread. BUFF was removed for many of the reasons that Jeff stated. People were doing all kinds of strange and unusual things with BUFF to provide filtering. Krow (of Slashdot fame) was getting a basic level of filtering with BUFF, and mod_gzip was another example of where BUFF was getting in the way of solving real-world problems. Note, it also solved some problems. mpm_perchild was markedly easier when we had the BUFF concept. (I can go into great detail if you all want me to).
As for an iol system, it really should be added to apr-util, assuming that the clean APIs remain available in APR proper. This gives you great flexibility and good performance. Also, since we are talking a lot about performance and APR 2.0, I want to mention again an improvement that I think should be made in APR 2.0. The incomplete structures were a great idea for APR 1.0, but I overused them. We should have used incomplete structures for the non-portable portions of each APR structure, but the portable stuff should have been accessible directly. A great example of this is apr_file_t->name. There is no reason to require a function call for this stuff. The current functions can and should be left for source compatibility, but for people wanting to directly access the common fields, they should be able to IMHO. Ryan On 6/24/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
david reid wrote: > James Mansion wrote: >> What's wrong with just using OpenSSL BIOs anyway? > > Nothing, but why layer upon layer when there is no real need? Also keep in mind that we *should* be able to link against netscape's SSL API invisibly; but building in sophisticated BIO related features would be fine for RSA SSLC or OpenSSL, but would stink when it comes to using other SSL implementations. I see every modern crypto provider supporting the API David's proposed, and the SHA/MD5 hashing I'm about to propose. The more 'special features' of one provider we define, the more code we will have to write when those API's are not present.
-- Ryan Bloom [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
