httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF EITO <>
Subject Re: 3.0 - Proposed Goals
Date Wed, 14 Feb 2007 16:28:20 GMT

> -----Ursprüngliche Nachricht-----
> Von: 
>  Im Auftrag von Justin Erenkrantz
> Gesendet: Mittwoch, 14. Februar 2007 16:45
> An:
> Betreff: Re: 3.0 - Proposed Goals
> On 2/13/07, Paul Querna <> wrote:
> > - Rewrite how Brigades, Buckets and filters work.  Possibly 
> replace them
> > with other models. I haven't been able to personally consolidate my
> > thoughts on how to 'fix' filters, but I am sure we can 
> plenty of long
> > threads about it :-)
> The collective design experiences behind serf tell me it's a lot
> easier (and performant) following's serf's bucket model.  Remember
> that serf's design came out of everyone's (me, Greg, Cliff, Roy, etc.)
> grief with filters and brigades and such - so I think it represents at
> least a good step in the right direction.
> I think httpd's bucket brigade model became overly complex and missed
> some goals.  I really like how Serf standardized on one model for
> 'input' and 'output' - which is a sore point with httpd's filters.
> Serf's buckets themselves are also about as close to Roy's original
> 'onions' model as you'll find anywhere.

Maybe we should keep in mind new possibilities like Linux's splice,
vmsplice and tee which could be useful for transfering files (local
on slow disks or on NFS) fast to a fast local cache.

> For those that haven't seen serf, it lives here now:
> So, it'd be nice if Serf would be a starting point - plus, if we

Plus, we could integrate serf itself into 3.x to

- Have a http client API available inside of the core httpd / module delivered
  with httpd which has been requested in the past.
- We could use this API to improve the http proxy (the current access method
  with the reversed filter chains seems to me some sort of a hack)
- Support things like OCSP which also need a http client API.



View raw message