apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 23:20:50 GMT
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" <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 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				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message