At 11:47 AM 6/21/2004, Bill Stoddard wrote: >William A. Rowe, Jr. wrote: > >>Thanks for the interesting references and citations. >>Apache HTTP server works at a lower level, below the layer exposed >>by this http.dll API. To actually use this interface would require a few >>things; >>1a) Either support the http channel with the apr_socket_foo() API (this >> is not a great option - because the interface is too high level and >> cannot be polled, etc) >>1b) or Implement an alternative core filter schema which works at the >> http.dll API layer > >1c) Use the apr_iol patch posted to the mailing list long ago. Reimplimenting >core_filter is not practically feasible (unless you have -lots- of time to waste >maintaining and debugging a new core_filter).
Scratch my proposal 1a) - your solution 1c) is the obvious choice if the user attempted to do this within apr... But it's not practical, in this case because http.dll isn't just another low-level interface, but a very high-level interface of an full http provider. And it turns out, core_filters are fairly trivial and the right solution. If anything is busted in the implementation of core_filter logic (that led you to claim it wasn't terribly practical), wouldn't 2.2 be the time to get this right? If you wanted to keep it very clean, you could even replace our http header filters, since they are preprocessed under this http.dll API. It seems overloading apr I/O is a long way around a trivial (logic) problem, didn't we already try and scuttle that very same sort of effort around our overloaded memory allocation strategy? Our conclusion was that the overloaded memory providers were too slow, and I'm afraid for this case that overloading in apr would create similar bottlenecks. Bill
