Ben Laurie wrote:
> I don't see why it matters if there are redundant members in
> request_rec. However, for purity, it might be cool to divide
> request_rec up into common elements and protocol-specific stuff in a
> union.
That's not really a problem, though of course it's hacky. It's the
logical consequence of declaring HTTPD to be multi-protocol while
making so much of it revolve around the request_rec.
> The downside of this approach, though, is that you could easily call a
> module that expected the wrong union to be filled in.
An extra magic number and an API like ap_verify_protocol(AP_PROTO_FOOTP)
could deal with that relatively cleanly. It can slot in well with
Paul's recent Listen/Protocol stuff.
> Another approach still would require a fairly large change to the core
> and many modules, but it strikes me as a better option...
>
> struct http_data {
> .
> .
> .
> };
>
> struct smtp_data {
> .
> .
> .
> };
>
> struct request_rec {
> .
> . /* common stuff */
> .
> struct http_data *http;
> struct smtp_data *smtp;
> }
The downside is back-compatibility: it'll imply a slightly bigger
change to modules. Nothing difficult, but third-party developers who
don't read this list may not take the trouble, leaving their users
in an incompatible world. That is a Bad Thing. Especially when half
the world hasn't forgiven us for incompatible changes in 2.x over 1.x.
It's the filter rec that really wants updating here. Currently we have
a conn_rec plus a request_rec. That's ugly: either the conn_rec is
redundant or the request_rec is junk - should be a union. With
additional protocols we just add more members to the union.
--
Nick Kew
