> > > The problem I have with this code idea isn't that it isn't useful to > > > httpd. It is that we have been down this road once, and the model wasn't > > > flexible enough. What problem are we trying to solve that the filter > > > mechanism doesn't solve? If the answer to that question is "filters are > > > in Apache, and we want this out of Apache", then move filters out of > > > Apache. > > > > No way man :-) > > Why not?
"No way man" is my answer to your question about possibly removing filters from Apache. Filters are good. :-) > > > > If the answer is, "We need a better way to abstract the network > > > for x, y, and z", then cool let's do it. > > > > I would argue that we do not have a good (read architecturally clean) way > > to abstract > > network io with filters. The NAL is a perfect compliment to the filter > > code. Here are my > > specific itches: > > > > 1. My SSL library API uses a different model than OpenSSL. Specifically, > > it uses uses > > secure_socket calls (e.g., secure_read(), secure_write(), etc.). I -could- > > integrate SSL > > into Apache 2.0 using filters, but I would have to replace > > core_inout_filter and > > core_output_filter with my own filters, possibly implement special bucket > > types > > (apr_bucket_secure_socket_t, etc.) With NAL, I can just hook the network io primitives > > with my own calls and use the filters already in Apache. I hope to use > > OpenSSL but that is > > just not a possibility now. My itch is real to me even if you don;t feel it > > :-) > > I'm not saying your itch isn't real, I'm saying I disagree with how you > want to scratch it. :-) > > > 2. I gave a pitch about IBM's Fast Response Cache Accelerator (aka AFPA) at > > ApacheCon a > > few years back. The AFPA implementation on Windows uses it's own socket API (afpa_read, > > afpa_accept, afpa_send, et. al.). Again, the NAL provides a clean way for > > my Apache > > module to hook the right NAL implementing my specific network io primitives > > with the > > minimum amount of shuffleing httpd code. > > > > Can I do both of these with filters? Sure, but the code architecturally > > ugly as sin. > > Allan Edwards solved both of these problems cleanly in early Apache 2.0 > > iterations using > > Dean Gaudet's IOLs. NAL is essentially a scaled back version of Dean's IOLs > > (NAL is > > focused just on network i/o, not filtering). And I know what Luke is > > talking about as > > well. Windows NT does implement filters (AFPA uses file system filters) in > > addition to a > > network io abstraction layer. NAL is a great compliment to filters. > > I'm saying that the code doesn't need to be architecturally ugly. The > problem, is that our core filters are big and do too much, IMNSHO. Break > out the core filters to smaller chunks that are available to other > filters, and I believe this will solve your problem completely. > I think you are saying that you believe it is possible to make the 'last filter' (currently the core_[input|output]_filter) a very thin filter whose primary purpose is to do network io; either via an apr_network_io interface, or via a custom interface? Is that about right? If so, I think that has some problems (perhaps solvable in a clean way). First problem is with where the network abstraction occurs. In the NAL, the abstraction is at the lowest possible level, at the core network io primitive level. With your solution, the abstraction occurs at the apr_network_io level. This means that my primitives will have to reimplement a lot of the buffering/locking/whatever code that is currently implemented in the apr_network_io code. Custom network io primitives must be semantically identical to the network io primitives they are replacing. It is much easier to do this at the socket level than at the apr_network_io level. Second, not all the network i/o we do is in the core filters. MPMs do network operations (accept, lingering close, etc.). Third, all the network io is done via apr_socket_t structs which are created in the MPMs and propogated to other parts of Apache. By definition, I am not interested in dealing with apr_socket_t structs (slightly modfied apr_socket_t structs maybe). How do we handle each place in the Apache code where we frob (look at, call an API with, whatever) an apr_socket_t and expect a real 'socket'? Where do I store my custom structure I use for networkio? I would like to be able to use the apr_socket_t structure and tweak it slightly for my custom calls, but that structure is opaque to Apache. Bill
