Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 79635 invoked by uid 500); 14 Apr 2000 23:40:47 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 79624 invoked from network); 14 Apr 2000 23:40:46 -0000 X-Authentication-Warning: koj.rkbloom.net: rbb owned process doing -bs Date: Fri, 14 Apr 2000 16:41:55 -0400 (EDT) From: rbb@covalent.net X-Sender: rbb@koj.rkbloom.net To: new-httpd@apache.org Subject: Re: I/O filtering in 2.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Fri, 14 Apr 2000, Greg Stein wrote: > On Fri, 14 Apr 2000 rbb@covalent.net wrote: > > On Fri, 14 Apr 2000 rbb@covalent.net wrote: > >... > > > > > @@ -2831,3 +2848,6 @@ > > > > > NULL) > > > > > IMPLEMENT_HOOK_RUN_FIRST(unsigned short,default_port,(const request_rec *r), > > > > > (r),0) > > > > > +IMPLEMENT_HOOK_VOID(filter, > > > > > + (request_rec *r, char *str, int len), > > > > > + (r, str, len)) > > > > > > > > This modifies the value in place. It doesn't make any provision for > > > > altering the length. Modifying in place implies making a copy of the data > > > > before passing it to the hook. Even then, you may not have enough buffer > > > > for the cases where the output is expanded. > > > > > > I'll say it again, easy first pass to show the basic outline of the code, > > > obviously the ability to extend the buffer's size is absolutely > > > necessary. That would have been added later. > > > > Actaully, the easiest way to solve all of this is to not use a char *, > > but instead to create an IOL that deals with a buffer. Then, just before > > calling the run_filters list, we copy into the IOL, and then pass the IOL > > around. This allows the buffer to be resized pretty easily. > > Well, yes, it could be an IOL. But having an IOL implies quite a few more > things than a simple layer structure (such as the one I posted). An IOL > has options, reading, close, shutdown, sendfile, etc. I believe a layer > only has "write" plus maybe some convenience variants (lprintf, lputs, > etc) No, having an IOL allows for those things, they don't require them, and since module writers will never see this stuff, it just means less duplication of code. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------