I go see them and fix them, on occasion. 8^) I think Graham does
something similar. Funny thing, that we think alike on this from a user
perspective.
What do you think of the c) - d) alternative, with the second release of
httpd (consider proxy as a filter in the release process) to be the one
the Big Boys use? I think that might be enough to keep the thing
running. 8^)
Chuck
On Thursday, April 19, 2001, at 02:36 PM, Ian Holsman wrote:
> my only concen with splitting the proxy out is that
> no one will actively maintain it, and keep it up to date
> with the current http releases.
>
> saying that i'm quite happy to volunteer myself to do this function,
> but i'm not an ASF member, or even have commit access for that matter.
>
> ..Ian
>
> ps .. are there any ASF members out there who work with large >10M
> hits/day sites?
>
>> -----Original Message-----
>> From: Chuck Murcko [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, April 19, 2001 11:06 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [VOTE] mod_proxy in?
>>
>>
>>
>> On Thursday, April 19, 2001, at 03:17 AM, Greg Stein wrote:
>>
>>> +1 on option c/d.
>>>
>>> time T: httpd releases httpd-2.0.x (no proxy)
>>> time T': proxy releases the module
>>> proxy team releases httpd+proxy bundle
>>>
>>> Basically, like (d) where the team can be self-directed,
>> but bundles are
>>> still released. An httpd release comes out, the proxy guys sync up,
>>> test,
>>> then release a proxy module and a proxy+httpd bundle.
>>
>> Now I get it. I wasn't getting that last step (bundled
>> release, but we
>> bundle it). I think we'd (developers on mod_proxy) prefer to
>> run closer
>> to c) just to minimize the code skew within proxy<->httpd release
>> development cycles. That's really been a headache for us
>> bugfixing. It's
>> the reason part of each of us (proxy people) just wants the
>> code to be
>> back in the core. It also makes enhancements available quicker.
>>
>> This may just also solve the converse complaint: that Big Sites want
>> this stuff bundled so they can Just Use It. Ian? Iain?
>>
>>> Even though I'm not seriously clueful on the proxy
>> development, I'm with
>>> Chuck in thinking there is a lot of
>> cool/interesting/bunches o' work
>>> that
>>> could be done on proxy. Mostly in the realm of caching, but also in
>>> increasing conformance and functionality. I also see
>> different packages:
>>> reverse, non-caching proxy (just a fancy gateway for
>> mapping multiple
>>> servers into one namespace); add caching; forward proxy;
>> add caching;
>>> etc.
>>>
>>
>> Cool. How about a connection pooling filter, generic? That's
>> on my list.
>>
>> Chuck
>>
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
