Thank you Roy...
> > Move the keepalives field out of the conn_rec and into an HTTP specific
> > connection record. This also moves some HTTP specific back out of the
> > core and into the HTTP module.
>
> -1. First, as I said at the hackathon, these variables are not specific
> to HTTP.
<snip>
>
> Third, I see no reason to make the Apache httpd code base generic to
> all protocols.
> If done at all, this work belongs in a different tree.
> I understand why it would be nice to have a multiprotocol routing core,
> but the current code base is nowhere near efficient enough to support
> such a change, certainly not without some justification from real users
> that need such a beast. We need to concentrate on getting it that way
> for at least SSL and HTTP.
I've been having these thoughts as well. Building a multiprotocol routing core is
interesting but
for now our efforts should be focused on getting a servicable HTTP Server. We are
diluting our
efforts spending time "adhoc'ing" the server to accomodate protocols other than HTTP.
>
> One of the things that needs to be kept in mind when building a
> multi-protocol server is that while many protocols carry the same
> elements, the applications that they support may have extremely
> different performance profiles.
> A server architecture has to be designed
> according to the application profile, not the syntax of the protocol that
> carries it.
I agree. FWIW, I attend an interesting presentation inside IBM over a year ago about
porting the
Lotus Notes server to Linux. There were some serious performance issues that had to
be handled in
designing the Notes server. Based on the performance requirements of that application,
the Apache
2.0 framework would not come close to doing what is needed. Apache 2.0 cannot become
all things to
all people. Let's focus our efforts on Apache 2.0 being an excellent HTTP server,
like Apache 1.3.
Bill
