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 Bill ----- Original Message ----- From: "Roy T. Fielding" <[EMAIL PROTECTED]> To: "Bill Stoddard" <[EMAIL PROTECTED]> Cc: "APR Development List" <[email protected]> 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 you > > saying I need an accept() filter, a recv() filter, et. al? Or that there > > needs to be a > > set of generic filter APIs created specific to manipulating network > > options? And that each > > 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 >
