apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: [PROPOSAL/PATCH] add ssl sockets
Date Sun, 18 Jun 2006 13:47:12 GMT
On 6/16/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> Jeff Trawick wrote:
> > On 6/13/06, david reid <david@jetnet.co.uk> wrote:
> >
> >> The attached patch is a first pass at getting some support for using
> >> openssl directly for ssl sockets within APR. I've tried to be generic in
> >> the basic configure code, but the actaul guts are basically openssl
> >> related.
> >
> > What about an I/O layering system for sockets?  This is in essence the
> > set of function pointers used by the one true sockets API to call out
> > to the details, as mentioned in other posts.
> Only one question.  If we are back to BUFF filtering from Apache 1.3, can
> we at least go back to history and look at why it was replaced by filtering?
> (Or would lurkers care to speak up?)

The BUFF API was completely inappropriate for the types of
transformations needed in httpd, and the requirement for plug and play
of arbitrary transformations was more than strong enough to warrant a
rewrite of the data handling around a more flexible API.  (And
applications that want to play in that space have to embrace that more
flexible API.)

BUFF had already been stretched too far, with the integration
(pollution) of chunking and charset recoding and perhaps some other
things I'm forgetting.  (ISTR Rasmus mentioning on-list that a
well-known site was using a BUFF hacked to provide compression.)

This is really fit-the-abstration-to-the-task, right?  BUFF was about
to explode with the  capabilities that were force-fitted into it.  A
socket API would too given the same requirements.  OTOH, you can
implement some advanced functions without busting the simple
abstration (i.e., without making the exploiting application a lot more

> Let's at least not add this performance hit where it isn't needed, and leave
> apr_socket_read/write alone.  More that I think about it, an apr_io_XXX() API
> for any application that prefers more abstraction would be a win, all around.


>  > OTOH, with more and more levels of indirection for function pointers and data
>  > you start to wonder if there is a noticeable performance hit.
> Isn't that why apr_sms_ was dumped?

a very big part
lack of obvious benefit was another part
the current allocator API seems to have started with a new look at one
of the goals of SMS

View raw message