httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 13:07:14 GMT
> From: Jeff Trawick []
> Sent: Tuesday, October 03, 2000 6:55 AM
> "William A. Rowe, Jr." <> writes:
> > > From: []
> > > ...
> > > I entirely expect to re-write mod_autoindex to use a single brigade to 
> > > pass data down, at far fewer buckets than it currently uses.  The only 
> > > reason I haven't done so already is that I have had bigger fish to fry 
> > > and very little time.
> > 
> > That's a given, and +++1's to you if you are the first to get to it :-)
> What you folks are saying is that the old API has been taken away.
> Previously we had APIs to write to the network which work like stdio.

Yes, that's what it did.

> Simple, easy-to-review/test code led to reasonable performance.

Very true.  I'd add limited flexibility to your list.

> Now you are saying that there is something wrong with such simple code 
> and it must be changed because it no longer performs reasonably.  I'd
> rather us *NOT* change mod_autoindex (much) but still make sure it
> still performs reasonably.

If you want mod_autoindex as the testcase/benchmark for the ap_r* suite,
I don't object to leaving it as is.  I think everyone is saying we need
the coalescing layer within:

  *) the ap_r* function support (handler source).
  *) the chunking filter (prevent tiny packetization).
  *) the core transport (or alternate transport) filter.

> > ap_r* is going away, correct?  It's legacy, and I'm not too
> > concerned.
> When did "we" drop the requirement to maintain the old API?

Thanks for a little dose of common sense, Jeff.  I agree that
ap_r* is still very legitimate.  I also agree that anyone calling
ap_r* has to assume they are buffered.  We can continue to define
the entire ap_r* as a simple case bucket-content-generator.  But it
must have it's own cacheing, as demonstrated by mod_autoindex.

We should also consider modifing the chunking filter. Rather than
literally coalescing buffers, we aught to simply group them, and 
the chunking filter hangs on to each until it has collected its 
threshold, insert its bucket[s?], and drop it all to the core.

The core filter can coalesce as necessary - e.g. transmitfile under
Win32 won't handle more than one char* of header and trailer, so we
generally create a single string for transmission.  Only the core
filter should worry about details like this, since it should be the
only one watching the flow.

View raw message