Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 19135 invoked by uid 6000); 12 Mar 1998 04:47:18 -0000 Received: (qmail 19122 invoked from network); 12 Mar 1998 04:47:16 -0000 Received: from ns2.remulak.net (HELO Mail.Golux.Com) (coar@198.115.138.27) by taz.hyperreal.org with SMTP; 12 Mar 1998 04:47:16 -0000 Received: (from coar@localhost) by Mail.Golux.Com (8.8.5/8.8.5) id XAA24379; Wed, 11 Mar 1998 23:45:41 -0500 Date: Wed, 11 Mar 1998 23:45:41 -0500 Message-Id: <199803120445.XAA24379@Mail.Golux.Com> From: Rodent of Unusual Size To: Apache HTTP developers Subject: [STATUS] (apache-2.0) Wed Mar 11 23:45:40 EST 1998 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: Release: 2.0 : In pre-alpha development see: Dean says: This sounds like I'm working on implementing this proposal. I'm not. Nobody is as far as I know. 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.0 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. * "Apache ports" project - simple-to-install (a la CPAN) one-off tools, scripts (such as counters, guest books, et cetera) * 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. * Replace the current Unix compilation model (Configuration.tmpl, home-brew Configure script) with the "autoconf toolset". Status: Brian +1, Roy +1, Dean +1, Ralf +1 * 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) Status: Jim +1, Ken +1, Marc +1, MarkC +1, Ben +1, Paul +1, Martin +1 * The "autoconf toolset" should include all three: autoconf, automake, and libtool. Status: Brian +1, Jim +1, Roy +1, Dean +1, Ken +1, Ralf +1, Martin +1 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. * multithreading. Status: Brian +1, Ken +1, Jim +1, Paul +1, Sameer +1, Marc +1, Ralf +1, MarkC +1, Ben +1, Martin +1 - Thread Abstraction Status: Sameer +1, Marc +1, MarkC +1, Ben +1, Dean +1, Paul +1, Martin +1 Volunteers: * revamped process model (Dean's proposal) Dean says: it's hard to do the multithreading work cleanly without considering a bunch of this Status: Marc +1 on much of it; threads aren't enough for perf. MarkC +1, Paul +1, Dean +1, Martin +1 Volunteers: * new layered I/O. Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1, Sameer +1, Marc +1, Ralf +1, MarkC +1, Ben +1 Volunteers: Ken . sfio Status: Dean -1 until it's shown to be thread safe (RST claims it isn't) Volunteers: . bstdio This was written by Chris Provenzano as part of his implementation of Posix threads... Jim can place a copy of the RST-hacked version on dev.apache.org if needed and possible. -- RST never donated his hacks to the Group. Don't put it up for download unless you've cleared it with him. --Brian . 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 asks: Is there some software flying around where such a model has been tried? Or is it a totally new technique? Status: Dean +1, Marc +1, Ben +1, Paul +1, Martin +1 Volunteers: * API work . radically revamped API Status: Ken +1 Volunteers: Ken . documented API Status: Ken +1, Sameer +1, Marc +1, Ralf +1, Paul +1, Dean +1, Martin +1 Volunteers: Ken . just new API phases Status: Brian +1, Jim +1, Sameer +1 (just the "gaping holes"), Ralf +1 (especially url2url and file2file in addition to url2file) Volunteers: Ken . change API 'phase' model to use module-registered hooks rather than a fixed static structure Status: Ken +1, Ralf +1, MarkC +1, Paul +1, Dean +1 Volunteers: Ken . use virtual functions for module hooks Status: Ben +1, Paul -1 Volunteers: . clearly identify API functions by renaming them Status: Ken +1, Ralf +1, Ben +1, Paul +1 (plus back compat.), Dean +1 Volunteers: Ken . backward compatibility with 1.3 (just require a recompile) if functions get renamed, old names retained as wrappers Status: Paul +1, Sameer +1, Marc +1, Ralf +1, MarkC +1 Volunteers: . make API call syntax rational (e.g., all r*() routines list r as their first argument, et cetera) Status: Ken +1, Ralf +0, Paul +0, Dean +0, Martin +0 Volunteers: Ken . abstract module layering for plugins (e.g., a mod_auth interface into which mod_auth_mumble modules can be plugged) Status: Ken +1, Martin +1 Volunteers: Ken * new configuration language Martin notes: There have been proposals to maybe make the config language XML-based. Status: Dean +1, Marc +1, Ralf +0, Ben +1, Paul +0, Martin +1 Volunteers: Ken * rewrite in C++ . Yes: Ben +1, Martin +1 . doesn't like the idea, but is open to it: Marc +1, Ralf +1 . No way ever: MarkC +1, Paul +1 . Not for 2.0, but maybe later: Ken +1 Volunteers: Closed issues: