On Friday 09 November 2001 12:38 pm, Bill Stoddard wrote: > 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
I have a plan for attacking these. I should have a patch in a little while. My thought is to move the socket out of the conn_rec. This will force us to do things in the right places. Ryan > > 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 -- ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
