rproxy as an Apache module Martin Pool The medium-term plan is that this code will become a module or two within Apache 2.x. These modules will do two distinct things: firstly be a proxy within the server framework provided by Apache, and secondly act as an in-process encoder for content generated by the server. Probably there will be two different modules to do this with some common code. Because we're planning to move into Apache there are some nice features we can count on Apache to provide for us. It's almost certainly not worth implementing these from scratch: * clever logging * error recovery and cleanup * full HTTP parsing/generation * forking/reuse/keep-alive of connections It should be pretty simple to glue rproxy in as a proxy. We might have to pay some attention to * keep-alive connections Perhaps a good way to do this is to glue in rproxy as an extension to the existing mod_proxy: after all, a lot of the intelligence about how to proxy requests is already there. But if we do that, then perhaps we should just go ahead and add it in a completely general way. From the point of view of integration, keeping the cache and decoding is more complicated, though the encoding part of the library contains the more sophisticated algorithm. To do hsync-encoding of locally-generated content * We need reasonably full IO-layers in APR, so that we can catch output wherever it's coming from. This is at least not well tested in Apache 2.0, but it can be fixed. * We need to settle the push/pull issue: if Apache expects to call us when it has output we have to modify the library to allow content to be pushed in, rather than having it call back when it wants input. I'm not going to worry about this for now. There may be some difficult issues when glueing these together * memory allocation: I'm somewhat inclined to just make sure the library doesn't leak and then to glue it into Apache as-is. This seems to be a reasonable approach for third-party libraries. If we can't achieve that e.g. when