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 19:40:03 GMT
On Mon, 9 Apr 2001, Greg Stein wrote:

> On Mon, Apr 09, 2001 at 08:15:03AM -0700, rbb@covalent.net wrote:
> > > > 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
>
> I had to hit "refresh" a bunch of times. It appears really flaky.
> Eventually, I got the front page, then after a bunch of refreshes, I got the
> patch page.
>
> [ using IE 5.5 ]

I don't have access to IE, and I haven't seen this problem yet.

> >...
> > > 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.
>
> No no no... I mean we create a new thing called ap_request. Keep request_rec
> in its current form, and the server (and modules) can use it. I think the
> ap_request would look something like:
>
>     typedef struct ap_request {
>         conn_rec *conn;
> 	apr_pool_t *pool;
>
>         /* ### point to something that describes the protocol which is
>            ### associated with this request */
>         void *protocol_module;
>
>         /* protocol-specific request data */
> 	void *protocol_req;
>
> 	ap_conf_vector_t *info;
>
>     } ap_request;
>
> protocol_req points to the request_rec.

I understand what you want.  I am saying that this doesn't actually
accomplish anything.  What this does is it says that every request has at
least two request structures, ap_request and http_request, regardless of
whether it is an http request.  The CORE requires some fields that are in
the http_request_rec.  If the core requires it, then it is a core field
and belongs in the request_rec, not the http_request_rec.

> In any case, we would also add one field to the request_rec:
>
>     ap_request *req;
>
> We can begin to move the main server over to using ap_request where
> possible. We can always get an ap_request from the request_rec and vice
> versa. The HTTP system would continue to use request_rec. We could even do
> something like:
>
>     typedef request_rec ap_http_request;
>
> And start making modules use ap_http_request for clarity.

This doesn't solve anything.  Try doing this please.  It doesn't really
work, because the CORE is using the fields.  If you do this, you are tying
the CORE to HTTP.  By removing fields slowly, we are weening the CORE from
it's reliance on fields, and we can make judgements over which fields are
required.

I have tried to remove many of the fields from the request_rec.  The CORE
was using them, which is why they have stayed in the CORE structure.  To
just move them to the http structure ignores the fact that the CORE is
using them.

> In any case... what I'm saying is introduce the new record, and we can
> slowly add items to it, and slowly begin using it. Adding items then becomes
> a more careful process "is <this> needed for the core server, or is it a
> legacy from the HTTP code?"

And what I am saying is that it is confusing enough as it is.  I would
much rather see us limit the number of structures, not add another one.
We can continue to pull fields out of the current request_rec as we have
time.

> I'm concerned that multi-protocol is coming from the wrong direction. Rather
> than starting clean and adding just the bits necessary, it is starting dirty
> and we're attempting to clean out bits. I don't think we'll ever get it
> cleaned out properly. There is too much legacy to do it well. The above
> should easily provide for legacy (request_rec is still around), yet
> introduces the "New Way" for eventual conversion. When the core no longer
> refers to "request_rec" or "ap_http_request", then we're done.

You are correct, this approach will never be perfect.  It will work.  To
do this perfectly, we will want to re-write much of this for 3.0.  I am
not suggesting that this is perfect, I am suggesting that this is a good
first step, and we can continue to improve it through the life of the 2.X
series.

> > > 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.
>
> I'm fine with the per-protocol request record referring to an auth_rec. No
> problem there. But building another layer into the core server doesn't sit
> well at all.

Why not?  How many protocols will use the state_rec?  How many won't?

Ryan

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


Mime
View raw message