httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Apache 2.0 for multi protocol usage
Date Mon, 09 Apr 2001 15:15:03 GMT
> > 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).

I am actually getting data on that page with Netscape and Konqueror

> > > 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.

This is much harder than it sounds.  The core actually uses the some
fields from the request_rec during processing.  This means that if we
start with a minimal request_rec, we will have an non-functioning server
until you either re-write parts of the core or add fields back to the
request_rec.  Or, we can start by removing stuff slowly, and continue to
have a functioning server.

> And punt that darn state_rec thing.

Punting the state_rec means that the only protocol that is optimized is
HTTP.  We can continue to optimize HTTP by having the request_rec have two
pointers, one to the state and one to the connection_rec.  That solves
this problem.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message