httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: Apache 2.0 for multi protocol usage
Date Mon, 09 Apr 2001 11:49:23 GMT
Greg Stein wrote:
> 
> On Sun, Apr 08, 2001 at 10:14:18AM -0700, rbb@covalent.net wrote:
> > On Sat, 7 Apr 2001, Greg Stein wrote:
> >
> > > Um... let's not forget that you haven't posted the patch(es) to new-httpd
> > > yet (i.e. most of us haven't seen them). It should not be committed until
> > > that happens. I think there are a number of concerns that people have (Roy,
> > > myself) with the proposed design.
> >
> > The patch was posted when we posted that we had a server running with the
> > patch.  A version that compiles and runs against HEAD can be found at
> > http://klomp.covalent.net:8080.
> 
> What MSGID or subject line? I can't find it. And I don't see a patch on that
> web server (it is just a blank page).

The patch itself was not posted. Only the URL. That email has still the
same subject-line. As this email (start of this thread).

> 
> > > For myself, I find the state_rec to be superfluous, and the overall intent
> > > feels like forcing some kind of commonality between protocols rather than
> > > providing a structure for multi-protocol (and then building on that). If
> > > pieces of protocols can be shared, then share the functionality, but don't
> > > put them into request_rec simply because two protocols happen to use them.
> > >
> > > Ideally, request_rec would contain only a few items. Things like a pool, the
> > > connection it is associated with, and a void* for the protocol-private
> > > information.
> >
> > I agree, that should be the goal, but it is a large goal.  This paper and
> > the corresponding patch are a first step.  We are moving in the right
> > direction, but we don't pretend to doing everything required.
> 
> It isn't a large goal. All you need to do is call request_rec "http
> specific" and introduce "struct ap_request" for the common piece. IOW, don't
> try to trim down request_rec (and ALL users), but introduce the new record.
> 
> We can then discuss what goes into ap_request. It can be quite small and
> clean.

That would even be a better approach for the implementation.
RyanB and I relied on the current request_rec since we
considered legacy and using what we have was a reasonable
approach.

> 
> And punt that darn state_rec thing.

Maybe, it is my english. What does this mean??

> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/



Mime
View raw message