On Mon, Apr 09, 2001 at 08:15:03AM -0700, [EMAIL PROTECTED] 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 ]
>...
> > 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.
Note that info is kind like request_config. I just hate the name foo_config
because it has nothing to do with config. It is extended information about
that item, handled by different modules in the system. foo_config is
confusing. Something like "info" or "per module data" or "private stuff" is
better.
Another alternative would be to say the protocol-specific information goes
into "info" and "protocol_req" is dropped. However, I would guess that only
one module is handling the protocol, so it is clearer to have the separate
field.
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.
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?"
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.
> > 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
