Sorry if I'm pain in the ass, but... > -----Original Message----- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 17, 2001 9:13 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] ApacheHTTPD -- WIN32
> > IMO that will Win9xConHook made unnecessary, and the NT+ platforms will > > benefit from the concept. > > Win9xConHook is a _hack_ for an unsupported platform. I'd sooner dump > 9x than attack the problem in this manner. We have fundemental issues > when we 'run-as-service' in 9x that Win9xConHook neatly wraps. If it's > broke, we aught to fix it. But we've critically broken CGI's many times > before trying to get this right. What we've got, works, well. I understand this, after all we are building a server, but don't you think that the time has come to make a decision to either drop the WIN9x from httpd, or still wasting like you said 200+ hours trying to solve unsolvable. > > I mean by that if the apache is run as service, it could call the > > ApacheHTTPD as 'redirector' for I/O. That way we could override the SSL > > password entry for example pushing some dialog box, or see the current > > server status. > > > Please review Oct 99 forward for new-httpd and take a look at the history, > so at least we aren't wasting time repeating prior discussion. Didn't found something like the thing I had in my mind. Perhaps I was unclear enough. For example right now we are having a app that: 1. start 2. print some status or whatever to stdout 3. eventually wait for same user feedback 4. registers for the status signal (quit, restart, whatever...) 5. run 6. print the current status 7. eventually wait for same user feedback 8. do 5 forever That is more or less the standard application we know. What I was thinking is to put some sort of a hooks in it that will allow one to get into the 'run' process itself. I'm not talking here about the modules dealing with the MIME or stuffs like that but rather the status of the apache itself. One of the simplest applications could be the ApacheHTTPD (another exe or a lib perhaps that checks the OS and command line), simply redirecting I/O to the window instead the console. The reason for that is IMO that if someone runs the apache in the non-service mode he is obviously testing something. Don't know how the pipe stuff can (if can at all) be resolved in that case, but the stdio can (in the same way as the ApacheMonitor). I was inspired to the concept looking at the rotatelogs util. We are communicating to that app using pipes and stuffs instead of using something like simple hook inside the apache that will intercept all the log directives, and if someone wants even send an email to the admin if there is more than a 100 requests for a particular page in a minute. Of course one could build a rotatelogs clone that deals with such a scenario, but imagine the chain of such utilities and the benefit. The ApacheHTTPD proposal IMO was the lead-in thought in the way that the app itself would behave in the following way: 1. start 1.1. Load all the app hooks 1.2. If we have a start hook run that, else use the old way 2. print the status using start hook's print function 3. eventually wait for some user feedback using startup hook's input function 4. registers for the status signal (quit, restart, whatever...) 5. run if some hook doesn't object 6. print the current status using some found hook's print function 7. eventually wait for same user feedback using some found hook's input function 8. do 5 forever Doing that (at least in the simplest way) wouldn't be IMO such a deal. I'm preferring the incremental software developement approach, so putting something like hooks for the printf/fprintf(stdio, ...), os version and command line should be the first things that need to be done. MT.
