Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 26336 invoked by uid 6000); 28 Jan 1998 00:40:45 -0000 Received: (qmail 26330 invoked from network); 28 Jan 1998 00:40:43 -0000 Received: from saga9.stanford.edu (171.64.15.139) by taz.hyperreal.org with SMTP; 28 Jan 1998 00:40:43 -0000 Received: (from akosut@localhost) by saga9.Stanford.EDU (8.8.8/8.8.4) id QAA24748; Tue, 27 Jan 1998 16:40:36 -0800 (PST) Date: Tue, 27 Jan 1998 16:40:36 -0800 (PST) From: Alexei Kosut To: new-httpd@apache.org Subject: Re: apache-2.0 In-Reply-To: <9801271340.aa21695@paris.ics.uci.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Tue, 27 Jan 1998, Roy T. Fielding wrote: > >But 2.0 won't be a complete rewrite and any attempt at starting from > >scratch would be ill advised, IMHO. We will never get anywhere. > > I disagree on all three points. It will be a complete rewrite or it > won't be called 2.0. Starting from scratch is not what we are doing -- > we are simply starting with a clean slate. And we will get a lot > further, faster, and with less friction if we can easily distinguish > the re-integrated software from stuff that's just lying around waiting > for someone to check to see if it is totally broken. I disagree completely. Doing a complete rewrite of 2.0 is definitely ill advised. For one thing, it's simply not neccessary. Much of 1.3 is very much code we want to keep. I'd say at least 75% of it. And many of the improvements I personally want to make, i.e., API changes, filtered I/O, etc..., are completely able to be added by making changes to the current code. And that's probably the best way to do it. Now I agree that doing an rm on http_main.c and http_config.c, and rewriting those sections from scratch, is probably a good idea, since we want to totally revise how Apache's process and config models work. But that's a small (albiet central) part of the code. Most of the modules, for example, work just fine, and will continue to work once they are ported to the 2.0 API (which should be, for the most part, as simple as changing some function names here and there). Most of the core code works just fine - http_request.c (again, new API stuff, but the basic principle's the same), http_protocol.c (if anyone suggests we rewrite this from scratch, I will maim them. I beleive more man-hours has been put into making the protocol code in Apache work right than in the entire rest of Apache). Except (again) for maybe the function names, there are very few problems with the pool (alloc.c) code. Same with the BUFF stuff. And the random utility (string/date/etc..) functions work just fine. I see no reason to rewrite them just for the heck of it. Apache 2.0 is whatever we call it. A year and a half ago, the plan was to release 1.1, and then merge rst's apache-XX changes into the tree and call that 2.0. And the apache-XX code was nearly identical to 1.1, with the addition of things like threading and sfio/bstdio. The only reason that plan didn't go forward is because we decided to go ahead with 1.2 first, and in the meantime, rst disappeared. We've been talking about 2.0 for two years. And I think that we will only continue to talk about it if we make it a complete rewrite. It has to be a revision of 1.x, or it will never be written. I believe very fully that we will be better off starting from 1.3, and replacing sections as necessary. Apache 1.3 contains (as of today's CVS build) 67,240 lines of code. That's a lot. That's 3,735 lines per person with CVS commit access. I know *I* don't want to rewrite that much code... > People should be encouraged to start building the core of 2.0 and > not have to worry about keeping the 1.3 and 2.0 repositories consistent. > If they want to see the old version history, they are perfectly capable > of switching to a 1.3 directory and viewing it there. -- Alexei Kosut Stanford University, Class of 2001 * Apache *