Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 6728 invoked by uid 6000); 18 Mar 1999 04:42:33 -0000 Received: (qmail 6662 invoked from network); 18 Mar 1999 04:42:29 -0000 Received: from i.meepzor.com (HELO Mail.MeepZor.Com) (cvs@204.146.167.214) by taz.hyperreal.org with SMTP; 18 Mar 1999 04:42:29 -0000 Received: (from cvs@localhost) by Mail.MeepZor.Com (8.8.5/8.8.5) id XAA07093; Wed, 17 Mar 1999 23:45:42 -0500 Date: Wed, 17 Mar 1999 23:45:42 -0500 Message-Id: <199903180445.XAA07093@Mail.MeepZor.Com> From: Rodent of Unusual Size To: Apache HTTP developers Subject: [STATUS] (apache-2.0) Wed Mar 17 23:45:40 EST 1999 X-Note: This is an automated message. Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Apache 2.0 STATUS: Last modified at [$Date: 1999/01/07 22:55:42 $] Release: 2.0 : In pre-alpha development Plan: Everyone with plans on things they want to do for 2.0 should add them to the repository now. Use a descriptive filename. Other code will be copied over when 1.3.? is finished. Showstoppers: Committed Code Changes: Available Patches: In progress: Needs patch: Open issues: * Library of routines to allow access to memory shared between processes, for things like per-module caches. Such shared segments should persist until the refcount drops to zero. It would be cool if pools could be created in such segments to allow things like shared tables and arrays. +1: Roy, Paul, Ken, Ralf, Martin, Lars * "Apache ports" project - simple-to-install (a la CPAN) one-off tools, scripts (such as counters, guest books, et cetera) +1: Roy, Paul, Ken, Ralf, Martin David Southwell has volunteered to work on this. -0: Lars [If we do this for modules only I'm +1, but I'm not very happy with scripts, tools or other stuff.] * Embed API documentation in the source, a la Java docs, so a script can extract the parameters and description and build a dictionary. If we do this, it needs to be *mandatory* in the style guide. +1: Ken, Lars * Maybe provide a syslog.conf-like means of directing different levels of server error messages to different locations. +1: Status: * Move authentication username (Basic) out of the conn_rec and into the request_rec where it belongs. With persistent connexions, it's perfectly reasonable for multiple realms to be referenced during the life of the connexion. Even though the conn_rec field is updated on each request when the password is requested by the auth routines, it's still not a connexion-oriented quantity. +1: Ken * Abstract the '+/-' capabilities of the Options keyword so other directives can use it without re-inventing the square peg. +1: Ken Status: Ken has volunteered to work on this. * Really, really comply with 2068 (or whatever Roy says is the right document). Like handling Vary response fields properly and reliably. +1: Ken * Improve mod_include SSI handling, perhaps by caching offsets to directives. Also, clean up the conditional syntax to allow formats that bear a faint resemblance to other usages (such as allowing "=~" and "!~") in other "languages," and provide for caseless matches. +1: Roy, Ken, Martin, Lars Martin sez: I've been thinking about replacing the parser by a recursive descent parser which would reduce complexity tremendously. * Apache reusable code library, wherein we can put some of the stuff developed during the HTTP project that would be useful elsewhere. We've got a start on this with libap, but it would be really cool to have things like the arrays, tables, pools, and related primitives moved into a library of which httpd is just a client and other things can be too. +1: Roy, Paul, Jim, Ken, Ralf, Martin, Lars * Replace the current Unix compilation model (Configuration.tmpl, home-brew Configure script) with the "autoconf toolset". +1: Brian, Roy, Dean, Ralf, Martin * Investigate replacing the current Unix compilation model (Configuration.tmpl home-brew Configure script) with the "autoconf toolset". (this varies from the above such that if it's shown that the "autoconf toolset" can do what we want, with less headache than what we have, then we go for it) +1: Jim, Ken, Marc, MarkC, Ben, Paul, Martin, Lars * The "autoconf toolset" should include all three: autoconf, automake, and libtool. +1: Brian, Jim, Roy, Dean, Ken, Ralf, Martin +0: Lars * Whatever we do regarding autoconf, we should be able to configure to build objects other than in the source tree. autoconf allows for this... you can do "mkdir obj; cd obj; ../configure". This is great for multiple platforms... or even on a single platform, one copy with profiling another without. (There are a lot of possibilities: creating shadow trees, VPATH-style Makefile settings, etc.) +1: Dean, Roy, Paul, Ralf, Martin, Lars * One of the main restrictions on Apache has been that we must assume a very low-level common denominator for the OSs out there. For example, Configure is always being derided as crappy, but it is restricted, by long tradition and common sense, to only use those capabilities that existed in the System 7 'sh' (eg: no function, etc...). One possible key to Apache's success is that it does not require any more than basic UNIX tools (and an ANSI C compiler) to build, compile and run. Many of the ideas floating around for 2.0 would, by default, (drastically) change this. Is this a good idea? [Roy: That overstates most of the changes proposed so far. In any case, older systems will continue to be supported by older versions of Apache -- it is not desirable to dull the cutting edge just so people nowhere near the cutting edge won't get cut.] FEATURE SET FOR 2.0 Here, we decide how many of the following feature ideas we will set for ourselves as work items for 2.0. We can't do everything we would want to, otherwise 2.0 will never be released. So please try and be conservative with your votes. Items in no particular order. Feel free to add more, but try not to duplicate earlier items too much. [Roy: The amount of time it will take to complete 2.0 will have very little to do with how much change is attempted --- it depends only on how many people can change things simultaneously, and thus many suggested changes will actually speed-up the overall schedule if they can help parallelize development or simplify the core code.] * multithreading. +1: Brian, Ken, Jim, Paul, Sameer, Marc, Ralf, MarkC, Ben, Martin, Roy, Lars o Thread Abstraction +1: Sameer, Marc, MarkC, Ben, Dean, Paul, Martin, Roy, Ralf Status: nobody has volunteered yet * revamped process model (Dean's proposal) Dean says: it's hard to do the multithreading work cleanly without considering a bunch of this +1: MarkC, Paul, Dean, Martin, Roy, Ralf, Lars Marc (+1 on much of it; threads aren't enough for perf.), Status: nobody has volunteered yet * new layered I/O. +1: Brian, Ken, Dean, Jim, Paul, Sameer, Marc, Ralf, MarkC, Ben, Roy, Lars Status: Ken has volunteered. o sfio_1998 Dean says it's not threadsafe. Specifically these need to be fixed: - sfprints.c has a "static Sfio_t *f" which would need to be made an auto for thread safety - sfcvt.c has a "static char *Buf"... needs to have similar change that we did to the cvt foo in apache - sftmp.c has a few statics... probably best to just lock in here - sfpopen.c has a couple statics that need initializing once - sfexit.c needs a few locks - sfmode.c Sfrsrv pool of buffers needs to be locked These can just be avoided: - the Stdio_b interface has a bunch of statics - the sfdcdos example discipline has a static There could be more... that was just a quick look around. But the perl folks seem to be using sfio, so they may have already looked into the threading issues. Also, the layering only provides for four primitives: read, write, seek, except (an exception mechanism). I kind of like NSPR's approach which has all the socket primitives in the list as well. It's also lacking the timeout parameters, because it wasn't specifically designed to deal with sockets like NSPR was. Roy talked to the authors (Glenn Fowler, David Korn, and Kiem-Phong Vo) at AT&T Research when he gave an Apache talk there in October. We might be able to get one of them to participate, or at least get answers to tough questions. o bstdio This was written by Chris Provenzano as part of his implementation of Posix threads. o page flipping friendly, page-sized buffer oriented, zero copy I/O (In this model there are functions like readbuf() which return a pointer to a buffer, rather than taking a pointer to a buffer. This is a lot like how kernels actually work. The advantage is that you can get zero-copy in the user space, which is a big win for caching modules of all sorts. You can also support the "traditional" slow style of stdio, which adds an extra user space copy.) [Martin: Is there some software flying around where such a model has been tried? Or is it a totally new technique?] [Roy: I did this type of buffer streams for libwww-ada95. The only problem is reclaiming buffers so that a large SSI won't suck up all available memory just sending it out the pipe.] +1: Dean, Marc, Ben, Paul, Martin, Roy +0: Jim [what about examples? Portability concerns?], Ralf, Lars o NSPR: Sameer thinks that we should evaluate NSPR (ns/nspr in the Mozilla source tree) and determine whether or not it sucks and decide if we can integrate it. It appears to me, from reading the NPL, that including NSPR in Apache 2.0 is legit. Vote +1 if you like NSPR, and want to use it. +1: +0: Sameer, Lars * API work o radically revamped API [Roy: presumably there is a goal in mind here?] +1: Ken, Lars Status: Ken has volunteered. o documented API [mom and apple pie] +1: Ken, Sameer, Marc, Ralf, Paul, Dean, Martin, Jim, Roy, Lars Status: Ken has volunteered. o just new API phases +1: Brian, Jim, Sameer (just the "gaping holes"), Ralf (especially url2url and file2file in addition to url2file) -1: Roy [that is what 1.4 would be like], Lars Status: Ken has volunteered o change API 'phase' model to use module-registered hooks rather than a fixed static structure +1: Ken, Ralf, MarkC, Paul, Dean, Roy, Martin +0: Lars Status: Ken has volunteered o use virtual functions for module hooks +1: Ben -1: Paul, Roy [would require two APIs] o clearly identify API functions by renaming them +1: Ken, Ralf, Ben, Paul (plus back compat.), Dean, Jim, Roy, Martin Status: Ken has volunteered [Roy: looks like it is already in 1.3] o backward compatibility with 1.3 (just require a recompile) if functions get renamed, old names retained as wrappers +1: Paul, Sameer, Marc, MarkC -1: Roy, Ralf, Martin, Lars o make API call syntax rational (e.g., all r*() routines list r as their first argument, et cetera) +1: Ken +0: Ralf, Paul, Dean, Martin, Roy, Lars Status: Ken has volunteered o abstract module layering for plugins (e.g., a mod_auth interface into which mod_auth_mumble modules can be plugged) +1: Ken, Martin, Ralf +0: Roy [needs more detailed proposal], Lars Status: Ken has volunteered * new configuration language +1: Dean, Marc, Ben, Martin, Roy, Lars +0: Ralf, Paul Status: Ken has volunteered, as has Ryan Bloom o use XML +0: Roy, Ralf * rewrite in C++ +1: Ben, Martin +0: Marc, Ralf, Lars -1: MarkC, Paul, Roy, Ken * make everything C++ friendly +1: Roy, Paul, Ken, Ralf, Martin, Lars Status: nobody has volunteered yet ("that damned pool decl" is fixed now) * Proxy enhancements (or drop proxy altogether?) for HTTP/1.1 and better ftp proxy Auth handling +1: Martin, Lars [we need at least a mini-proxy for things like reverse-proxying etc.] Closed issues: