httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason S. Clary" <>
Subject Re: Hello.. and why stick with NCSA config format?
Date Thu, 09 Jan 1997 21:08:23 GMT
Hmm, this brings up a good point... SSLRef 3.0 has IO buffering built in.. its
a required part of the SSL protocol if you want to implament non-blocking IO
because SSL can't send until its got a block of the right size or a timeout

> From: Alexei Kosut <>
> To:
> Subject: Re: Hello.. and why stick with NCSA config format?
> Date: Thursday, January 09, 1997 10:39 AM
> On Thu, 9 Jan 1997, sameer wrote:
> > 	wtf respect to the API stuff... I am all for a few additional
> > handlers going in soon, which rings me back to the 1.3 heresy. I am
> > *completely* against delaying 2.0 development, but I think a 1.3 with
> > a better API should come out within the next 6 months, well before 2.0
> > can come out.
> Not true, IMHO. Assuming we can get RST to say something... as I
> recall, his threaded version of Apache was pretty much done a few
> months ago, and current with the 1.2 code to that point. All we would
> need to do would be to update it such (he may have already, I don't
> know), make it work on all the platforms, add the "extra" stuff that's
> been lying around
> Remember, we were supposed to have 1.2.0 out by the end of August, and
> then we were going to get right to work on 2.0. It's January
> already. Don't bother talking about a 1.3, please... I'm vetoing it
> right now.
> > 	I think the IO handlers are best left for 2.0, actually,
> > because threading allows for protocol layering, but there might be a
> > use for it sooner.
> Threading has nothing to do with protocol layering, unless you are
> layering in a threaded protocol (like MUX or HTTP-NG). However, RST's
> Apache did have layered protocol functions, using either sfio of BSD's
> funopen(), which worked rather well. I've been thinking that another
> layer of API abstraction would probably be desired, rather then
> letting the modules play directly with the IO streams, but that's not
> hard.
> The point being that once you have stream functions that support
> layering well (BUFF doesn't), it's trivial to add it to the API.
> -- 
> ________________________________________________________________________
> Alexei Kosut <>      The Apache HTTP Server
> URL:

View raw message