httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: mod_smtpd design.
Date Fri, 01 Jul 2005 13:35:10 GMT
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

View raw message