apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: [PATCH] APR Socket IOL
Date Fri, 09 Nov 2001 19:39:29 GMT
> 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
> set of generic filter APIs created specific to manipulating network options? And that
> 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].


View raw message