httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <ab...@dial.pipex.com>
Subject Re: axe proxy support from 2.0?
Date Sat, 13 Nov 1999 20:04:14 GMT
Maybe I'm well off the mark here, but if we add an "ap_remote_retrieve"
function to APR and add the necessary support into Apache, couldn't a
rewritten proxy module make use of it?  If that's the case then I suggest we
start out along the road of adding the remote fetch capability then once
things are more stable we can re-assess whether or not a full blown proxy
module is required.  In the mean time why not create a subdirectory
alongside experimental called "old" or some such and move the proxy stuff in
there until we figure out in the fullness of time what's happening with it.

How does that sound to everyone.  We're all agreed that the remote fetch
stuff will be useful, so I see no real problems bar someone volunteering to
add the functions to APR.  Don't really want to drop it onto Ryan, he's
already got too much to do!  No, I'm not volunteering either!

Just another 2p worth...

david
----- Original Message -----
From: Greg Stein <gstein@lyra.org>
To: <new-httpd@apache.org>
Sent: 13 November 1999 19:54
Subject: Re: axe proxy support from 2.0?


> On Sat, 13 Nov 1999, Eli Marmor wrote:
> > I didn't express my opinion in this issue so far; I don't think that
> > my opinion is so important, I'm not one of the core developers, my
> > contributions to the development of Apache were too humble, and I
> > didn't want to make anybody angry.
>
> As I mentioned previously... your opinion (and others') is always
> valuable. It provides some guide before we go and do something silly :-)
>
> >...
> > I remember that less controversal proposals, such as integration of
> > the EAPI code (please don't flame; Just an example!), were denied
> > very easily, although most of the developers wanted them. In some
> > cases, even an objection of ONE developer, sent an idea to the
> > trashcan (these are the rules, aren't?).
>
> Yes, any developer can veto any change.
>
> One of the issues with EAPI was timing, rather than issues with the patch
> itself. I believe it stands a much better chance for 2.0 :-)
>
> (note that hooks are in 2.0 already and MM is sitting there but not fully
> folded in yet)
>
> >...
> > I think that if it is so critical and important to axe it out, maybe
> > it will be better to just add a disclaimer (like in the case of the
> > WIN32 port) that it is not 100% stable (although IMHO it IS), or add
> > a recommendation to use Squid. In any case, don't forget that the
> > default configuration of httpd.conf is "ProxyRequests Off", and
> > nobody is forced to uncomment the "#ProxyRequests On". So even a
> > disclaimer and/or recommendation to use Squid, is already a huge
> > compromise.
>
> At the moment, the disclaimer would be "this code might not even compile,
> let alone function." While it may be stable for 1.3, we're talking 2.0
> here.
>
> (actually, I don't have a real handle on how *close* the code is to
> working; it might work fine for all I know; part of my impetus for change
> is to reduce our bug count caused by something that I don't feel "belongs"
> in a web server; the remote-fetching concept makes good sense, tho)
>
> So it isn't really so much "critical/important" to axe it, as it is a
> recognition that something needs to be done.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>


Mime
View raw message