apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <rbl...@gmail.com>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Sat, 24 Jun 2006 20:54:11 GMT
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.


On 6/24/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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

View raw message