William A. Rowe, Jr. wrote:
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?
I tried for a few months (a few years ago) to maintain custom core_*_filters to interface to IBM's Windows kernel resident caching GET engine and it was -way- more trouble than it was worth. Apache core*filters are a moving target and I spent a huge amount of time debugging problems in both the customer filters and the apache core filters. The apr_iol patch solved the problem for me perfectly. The apr_iols allowed me to use the Apache core filters and benefit directly from all the testing provided by the user community. Using apr_iol reduced the size and most importantly the complexity of the custom code I had to maintain. I know nothing about the httpd.dll, so maybe iols would be useful, or maybe not. They were useful for me for a similar (in concept) application. YMMV.
Bill
