| The User-Developer Convergence: Innovation and Software Systems Development in the Apache Project | ||
|---|---|---|
| Prev | Chapter 7. Vignettes of software systems development | Next |
Randy Terbush has the patch for a new feature:
It is a fairly busy day on the new-httpd mailing list, and Terbush' e-mail seems to be lost in the general activity. Administrativia is pretty much the order of the day. A total of 11 messages are submitted in a discussion about the project's name. Another 2 messages deal with setting up a home page for the project. Cliff Skolnick has set up a script that sends an e-mail to the list every time a patch is submitted or updated, generating another 19 computer generated messages in addition to the 28 sent by the project members. For whatever reason there is no reply to Terbush' message, and no patch is submitted.Something I have not seen discussed on this list is the possibility of adding a "Multi-homed" support feature. I have a *small* patch as implemented by Bob Baggerman that I could place on hyperreal. Would the group prefer that I contact Bob and ask him to submit the patch himself?. [TERBUSHMAR95A](Terbush, posted on the new-httpd mailing list March 10 1995)
A few weeks pass by, but Randy Terbush seems not to have given up on the idea of multi-homed support:
Cliff Skolnick has gotten a head start on Terbush. He has implemented this feature already, but not yet submitted the patch due to an unfixed error with logging [SKOLNICKAPR95A](Skolnick, posted on the new-httpd mailing list April 1 1995). Skolnick's patch is submitted a short week later on April 6 [TERBUSHAPR95D](Terbush, posted on the new-httpd mailing list April 6 1995), and slightly updated by Randy Terbush the next day [TERBUSHAPR95D](Terbush, posted on the new-httpd mailing list April 7 1995). The patch is not met with immediate enthusiasm. David Robinson doesn't like the way it is implemented, nor how it is being configured [ROBINSONAPR95A](Robinson, posted on the new-httpd mailing list April 9 1995). He argues that one should instead run several httpd processes, each listening on a different IP address. This would require no changing of the code, instead utilizing the features provided by the sockets API. The nasty side effect of this, as Cliff Skolnick points out, is that this requires having several independent configuration files [SKOLNICKAPR95B](Skolnick, posted on the new-httpd mailing list April 9 1995).I was just beginning to hack on multi-homed support. The changes are fairly minor and I wanted to ask the group what their thoughts are about implementation.
The direction I would like to take would be to reset 'DocumentRoot' based on the answering IP address (ie the IP that the server is answering for). I see it being much like 'ScriptAlias' such that if the IP contacted is 200.100.50.1, DocumentRoot gets set to /www/docs/200.100.50.1.
Comments?
The other implementation I have seen sets a CGI environment variable to SERVER_ROOT which requires an index.cgi to be in the toplevel document directory. Seems like all of those execs could add up to a lot of overhead. [TERBUSHAPR95A](Terbush, posted on the new-httpd mailing list April 1 1995)
Skolnick's second objection to running independent httpd processes is based on a future projection. He says "when non-forking is standard" [SKOLNICKAPR95B](Skolnick, posted on the new-httpd mailing list April 9 1995), think of the consequences running separate processes will have on performance. Running all within a single process and its child processes makes the Web server scale better as resources may be shared between the virtual hosts. Robert S. Thau steps in to further support Skolnick's argument for running all in one process. Their argument is based on experience: "Given the peakiness of Web loads, most processes in a server pool are likely to be idle most of the time --- they're there anyway so the server doesn't have to fork, and get even slower, in response to transient load peaks" [THAUAPR95B](Thau, posted on the new-httpd mailing list April 9 1995).
As for Robinson's objection to the user-friendliness of Skolnick's virtual host patch—"Using virtual hosts requires an understanding of the DNS and TCP/IP that most people don't have. The current patch really confuses the issue by pretending that it is selecting on the hostname the user used, whereas it is really selecting on the ip-address the browser uses" [ROBINSONAPR95A](Robinson, posted on the new-httpd mailing list April 9 1995)—there are no replies to it. The format will remain the same throughout the entire lifetime of Apache 0.x and 1.x series.
When votes are up for release 0.5 on April 8 [HARTILLAPR95B](Hartill, posted on the new-httpd mailing list 8 1995), the virtual hosting patch's reception is still luke warm. While there are no vetoes for the patch, it still hasn't gotten sufficient votes to make it into the next release. In the nick of time Brian Behlendorf submits his votes [BEHLENDORFAPR95B](Behlendorf, posted on the new-httpd mailing list April 8 1995), and virtual hosting makes it into the 0.5 release. While some consider virtual hosting a strategic important feature in competition with other Web servers [TERBUSHAPR95E](Terbush, posted on the new-httpd mailing list April 8 1995), the majority of the Apache developers seem indifferent.
Under the surface of this vignette, there is an argument between aesthetics and practicalities. Robinson's objection over the feature is based on a minimalist approach to programming. Apache has a command-line option to specify the location of the configuration file. The configuration file has an option to determine what port to bind the Web server to. The operating system itself supports running several processes of an application. Robinson's argument is one of the approach of least effort, a practical application of the keep it simple stupid philosophy [RAYMOND1999B](Raymond 1999b). While having practical implications, the keep it simple stupid philosophy is really one of aesthetics. It is reflected in the credo "good programmers know what to write, great programmers know what to rewrite (and reuse)" [RAYMOND1999](Raymond 1999, p. 33). Reuse requires having understood not only the problem to be solved, but also existing technologies.
Skolnick's argument is of a more practical mind, but also contains elements of reuse. His primary argument is one of resource management. A single process approach to virtual hosting allows several Web sites to better make use of the same resources. Having several processes doing the same thing running on a same system is a waste of resources. Instead of competing over the resources, the Web sites can make use of the possibility that different Web sites have different traffic peaks. Skolnick's secondary argument is one of convenience as well as reuse. If the same configuration file can handle several virtual hosts, settings common to the hosts may be shared and thereby reused. Settings specific for a virtual host is found in the configuration part specific to that virtual host. Having the entire configuration in one file is considered advantageous as it saves time having to find and open several files when configuring a virtual host.