apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 20:38:39 GMT
Thank you for a perfect explanation.  Now I grok and agree!

The work that needs to be done:

1. Figure out how to set network io options via the filter API and move all these network
apr calls that live outside the filter chain into the filters.

2. Add a couple of additional filters, net_in and net_out that live below core_in and
core_out respectively

3. move the apr network io calls out of core_in and core_out into net_in and net_out


----- Original Message -----
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: "Bill Stoddard" <bill@wstoddard.com>
Cc: "APR Development List" <dev@apr.apache.org>
Sent: Friday, November 09, 2001 2:39 PM
Subject: Re: [PATCH] APR Socket IOL

> > I have an socket-like API. I need to issue my_accept(), my_setsockopt(), my_recv(),
> > my_send(), my_sendfile(), et. al. These calls are scattered all across httpd. Are
> > saying I need an accept() filter, a recv() filter, et. al?  Or that there needs
to be
> > set of generic filter APIs created specific to manipulating network options? And
> > filter should grok these APIs and pass them down all the way to the network layer?
> The filter API is supposed to be an abstract IO layer that is implementation
> independent.  That doesn't mean lowest-common-denominator -- it simply means
> that all IO calls must go through the filter chain in order to be interpreted
> properly.  Any code that sets IO options without going through that chain
> is a bug, because the users of filters do not know what exists underneath
> the filter, and filters themselves do not know what is underneath the next
> filter down the chain, so attempting to set socket options based on the
> theory that the bottom of the chain is a socket will be an abstraction
> violation that will eventually bite someone in the ass.
> In other words, if the socket calls are spread all over the code, the
> solution is to find a way to direct those calls through the filter stack
> so that they can be interpreted by the socket-interface filter, since then
> you can simply replace the socket-interface filter at run-time with one that
> uses your special library calls, and the result is no extra overhead for
> anybody and a cleaner separation between Apache code and third-party code.
> I don't know if it is possible to do that with the current API, but I
> do know that the whole idea of filters doesn't work if any abstraction
> violations are allowed [which is already a problem because metadata is
> not being passed through the chain].
> ....Roy

View raw message