httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: Apache 2.0 for multi protocol usage
Date Mon, 09 Apr 2001 11:21:03 GMT
Greg Stein wrote:
> 
> Um... let's not forget that you haven't posted the patch(es) to new-httpd
> yet (i.e. most of us haven't seen them). It should not be committed until
> that happens. I think there are a number of concerns that people have (Roy,
> myself) with the proposed design.

Although, the patch is not submitted. It is available at the URL
provided. I also understand you and Roy have some concerns.
For those concerns I would invite you to speak them out here.
I am aware of yours and ROys since you reviewed the document
for RyanB and me.

> 
> For myself, I find the state_rec to be superfluous, and the overall intent
> feels like forcing some kind of commonality between protocols rather than
> providing a structure for multi-protocol (and then building on that). If
> pieces of protocols can be shared, then share the functionality, but don't
> put them into request_rec simply because two protocols happen to use them.

If I may be honest. HTTP is almost the only protocol that would not
directly need the state_rec (since is does not currently). However,
most other protocols need this. So by saying Apaxche could be a
multiprotocol, it is short sighted to look only to the requirements
for HTTP. Other protocols which benefit from thise extra layer are:
POP, IMAP, FTP, RTSP, BEEP. So far there is only one protocol, SNMP,
besides HTTP that does not really need it.

> 
> Ideally, request_rec would contain only a few items. Things like a pool, the
> connection it is associated with, and a void* for the protocol-private
> information.

Yes, that would be ideal. I understand that the current proposal
leaves various items in the request_rec. The reason is of legacy.
When RyanB and I came up with this we had various discussions
on where to put things. That some stayed in the request_rec was
because of the overall influence on Apache. RyanB had good
examples of why we better should leave it there for now.
Although, we would like to see it evolve over time.

Harrie

> 
> Cheers,
> -g
> 
> On Fri, Apr 06, 2001 at 10:46:18AM -0700, Harrie Hazewinkel wrote:
> > Bill Stoddard wrote:
> > > Harrie,
> > > I am -0 on committing this code as-is but +1 on the concept.
> >
> > Cool that you like the concept.
> >
> > > I spent some time
> > > looking at the code and in general it looks okay, but there is too much to
> > > review and do a good job of it.
> > >
> > > I recommend you break this patch into a minimum of three seperate patches.
Do
> > > a patch that just does the code moves from protocol.c to http_protocol.c (no
> > > function change and no new code other than what is required to accomodate the
> > > move), another patch that introduces the http_request_rec and http_conn_rec,
> > > then another patch the introduces the state_rec. Make sense?
> >
> >
> > Makes sense. It is a huge patch and understand that breaking it up in
> > pieces would make acceptance easier. A problem could be that it is
> > almost an atomic step.
> >
> >
> > Harrie
> 
> --
> Greg Stein, http://www.lyra.org/



Mime
View raw message