> 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
