Philosphical help - module or CGI

[Kean Johnston]

Good morning all,

For a (private) project I am working on, I would appreciate a little 
advice. The system produces mostly dynamic content, very little static 
stuff. A lot of the data that will be served up by httpd comes from a 
daemon running on the same host, and all of the required data is in a 
shared memory segment. I can obviously go two ways, and I would 
appreciate some guidance as to which is best. Performance is the 
ultimate criteria I guess. Im not scared o writing a module :)

I can either produce the content with a CGI that attaches to the shared 
segment, gets the data and renders it in HTML, or I can write a module 
that does the same thing. I assume that simply doing a read-lock with a 
SysV semaphore and a shared memory attach has to be faster than doing an 
exec of the CGI program, even one that will be executed extremely 
frequently and almost always in core. Of course, I can hack the web 
server to my hearts content, and possibly even have the main httpd 
create the semaphores and shared memory segments, so that when it 
preforks, all of the children already have all of those set up and 
simply need to use the semaphore for the read lock, render the data from 
the shared segment and be done with it.

Do you think it would be overkill to write this as a module, or would 
the simplicity gained by writing a normal CGI be worth it? I've not 
written an Apache module before, so it would be a bit of a learning 
curve, but a worthwhile one I think. If you think the module route is 
the best way to go, where is a good place to look for a module that is 
simply a content-producer ... would the status stuff be a good place to 
look for an example? The only wrinkle is it will need access to the 
headers for cookie purposes, which I dont think the status code uses, 
but Im sure I can get access to the headers easily enough.

I intend to implement this using httpd 2.0, if that makes any difference.

Thanks in advance for any opinions or advice offered.

Kean