You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/07/18 05:45:39 UTC
[STATUS] (apache-2.0) Fri Jul 17 23:45:37 EDT 1998
Apache 2.0 STATUS:
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.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.
+1: Roy, Paul, Ken, Ralf, Martin
* "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
* 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
* 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
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
* 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
* The "autoconf toolset" should include all three: autoconf, automake, and
libtool.
+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. (There are a lot of possibilities: creating shadow trees,
VPATH-style Makefile settings, etc.)
+1: Dean, Roy, Paul, Ralf, Martin
* 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
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
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
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?], Ralf
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
* API work
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, Martin
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
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, Ralf
+0: Roy [needs more detailed proposal]
Status: Ken has volunteered
* new configuration language
+1: Dean, Marc, Ben, Martin, Roy
+0: Ralf, Paul
Status: Ken has volunteered
o use XML
+0: Roy, Ralf
* rewrite in C++
+1: Ben, Martin
+0: Marc, Ralf
-1: MarkC, Paul, Roy, Ken
* make everything C++ friendly
+1: Roy, Paul, Ken, Ralf, Martin
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
Closed issues:
Re: Is it time for some 2.0 philosophy/design talk yet?
Posted by Ben Laurie <be...@algroup.co.uk>.
Simon Spero wrote:
> For example, It's a lot easier to write code that uses a stream interface for
> reading and writng; however this turns processing into a two step affair, and will
> need a thread-context-switch. This is fast enough to probably not be too much of a
> hassle (especially if you've already paid for a system call to get the data into
> user space. However, this style of coding doesn't fit too well when things start
> getting pushed into the kernel, where an up-call style interface is much more
> suitable. The best solution might be a hybrid approach - it's trival to write an
> adapter to turn an up-call interface into a stream by writing a module to push
> stuff into a queue, but it's harder to go the other way.
This is what we did with RST's threaded implementation, AAMOI. It's a
good idea, I think, to do it this way.
> A smart middle-end that can
> mix up an appropriate stack from a number of candidate implementations (ILP ,etc)
> could go a long way to smoothing the differences. [This would probably be a lot
> clearer with an example - a good one is combining SCP/MUX with HTTP and
> Compression; let me know when the release is done and I'll starting posting some
> shit if people are interested
I'm interested.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: Is it time for some 2.0 philosophy/design talk yet?
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Sun, 19 Jul 1998, Simon Spero wrote:
> I've been holding off posting some thoughts since there's a release in
> the air, and I don't want to speak up and risk losing any fingers.
Any fingers lost will be reimbursed by the Apache Group with copies of
Apache, valued at $995 each (that's about the going price for a web
server, hmm?) So, for example, if you lose a finger, and it costs $30,000
to stitch it back on, you will receive 31 copies of Apache. We'll even
throw in a copy of the source code, just to help you recover!
[...]
> let me know when the release is done and I'll starting posting some shit
> if people are interested
I think it's all right to start posting now. I plan to post some of my
ideas as soon as I get a few hours to think them out and write them down.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Is it time for some 2.0 philosophy/design talk yet?
Posted by Simon Spero <se...@unc.edu>.
I've been holding off posting some thoughts since there's a release in the air, and
I don't want to speak up and risk losing any fingers.
I've been trying to come up with a more detailed description of the kind of API
model I was talking about the other week, and there are a lot of tradeoff points
that I'd like to thow up for discussion. I think I have a model that lets backend
objects obtain method implementations from multiple implementations relatively
cleanly with much faster dispatch.
However there are a lot of issues that show up in the front end, especially when it
comes time to deal with flat stacs o'transports, and hybrid kernel/user-space
designs where the same code could be kernel resident or called in user space
depending on configuration.
For example, It's a lot easier to write code that uses a stream interface for
reading and writng; however this turns processing into a two step affair, and will
need a thread-context-switch. This is fast enough to probably not be too much of a
hassle (especially if you've already paid for a system call to get the data into
user space. However, this style of coding doesn't fit too well when things start
getting pushed into the kernel, where an up-call style interface is much more
suitable. The best solution might be a hybrid approach - it's trival to write an
adapter to turn an up-call interface into a stream by writing a module to push
stuff into a queue, but it's harder to go the other way. A smart middle-end that can
mix up an appropriate stack from a number of candidate implementations (ILP ,etc)
could go a long way to smoothing the differences. [This would probably be a lot
clearer with an example - a good one is combining SCP/MUX with HTTP and
Compression; let me know when the release is done and I'll starting posting some
shit if people are interested
Simon