fielding 98/03/25 23:13:44
Modified: . STATUS
Log:
Add my comments/votes. Fixed the formatting and removed the
kindler, gentler form of saying "piss off" to a proposal.
Revision Changes Path
1.30 +108 -92 apache-2.0/STATUS
Index: STATUS
===================================================================
RCS file: /home/cvs/apache-2.0/STATUS,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- STATUS 1998/03/17 15:00:24 1.29
+++ STATUS 1998/03/26 07:13:43 1.30
@@ -3,9 +3,6 @@
Release:
2.0 : In pre-alpha development
- see: <http://www.arctic.org/~dgaudet/apache/2.0/process-model>
- Dean says: This sounds like I'm working on implementing this
- proposal. I'm not. Nobody is as far as I know.
Plan:
@@ -28,14 +25,17 @@
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
* "Apache ports" project - simple-to-install (a la CPAN) one-off
tools, scripts (such as counters, guest books, et cetera)
+ +1: Roy
* 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."
+ +1: Roy
* Apache reusable code library, wherein we can put some of the stuff
developed during the HTTP project that would be useful elsewhere.
@@ -43,28 +43,29 @@
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
* 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
+ +1: Brian, Roy, Dean, Ralf
* 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
+ +1: Jim, Ken, Marc, MarkC, Ben, Paul, Martin
* 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
+ +1: Brian, Jim, Roy, Dean, Ken, Ralf, Martin
* 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.
- Status: Dean +1
+ +1: Dean, Roy
* 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,
@@ -76,6 +77,11 @@
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
@@ -83,105 +89,115 @@
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.
- 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:
+ +1: Brian, Ken, Jim, Paul, Sameer, Marc, Ralf, MarkC, Ben, Martin,
Roy
+ o Thread Abstraction
+ +1: Sameer, Marc, MarkC, Ben, Dean, Paul, Martin, Roy
+ 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
- Status: Marc +1 on much of it; threads aren't enough for perf.
- MarkC +1, Paul +1, Dean +1, Martin +1
- Volunteers:
+ +1: MarkC, Paul, Dean, Martin, Roy,
+ Marc (+1 on much of it; threads aren't enough for perf.),
+ Status: nobody has volunteered yet
* 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.
-
- . 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?
- Jim asks: examples? Portability concerns?
- Status: Dean +1, Marc +1, Ben +1, Paul +1, Martin +1, Jim 0
- Volunteers:
+ +1: Brian, Ken, Dean, Jim, Paul, Sameer, Marc, Ralf, MarkC, Ben, Roy
+ Status: Ken has volunteered.
+
+ o sfio
+ -1: Dean [until it's shown to be thread safe (RST claims it isn't)]
+
+ 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?]
* 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, Jim +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,
- Jim +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
+ o radically revamped API
+ [Roy: presumably there is a goal in mind here?]
+ +1: Ken
+ Status: Ken has volunteered.
+
+ o documented API [mom and apple pie]
+ +1: Ken, Sameer, Marc, Ralf, Paul, Dean, Martin, Jim, Roy
+ 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]
+ 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
+ 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
+ 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, Ralf, MarkC
+ -1: Roy
+
+ 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
+ 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
+ +0: Roy [needs more detailed proposal]
+ Status: Ken has volunteered
* 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
+ +1: Dean, Marc, Ben, Martin, Roy
+ +0: Ralf, Paul
+ Status: Ken has volunteered
+
+ o use XML
+ +0: Roy
* 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:
+ +1: Ben, Martin
+ +0: Marc, Ralf
+ -1: MarkC, Paul, Roy, Ken
+
+ * make everything C++ friendly (fix that damned pool decl)
+ +1: Roy
+ Status: nobody has volunteered yet
Closed issues:
