httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr_ v.s. ap_
Date Tue, 04 May 1999 11:27:17 GMT
Ryan Bloom wrote:
>...
> On Mon, May 03, 1999 at 05:07:03PM -0400, Ben Hyde wrote:
> > ap_ is good because is reduces the amount we will have to redo
> > code in Apache and in all the down stream modules.  I think you
> > have to have a pretty strong argument to force all that code to
> > change.  I haven't heard a strong argument for this one.
> 
> I would just like to remind everybody that ALL that code has to change
> anyway.  There will be NO way that 1.3 modules will work with 2.0.  This
> is because 1.3 uses int's as files and sockets, and 2.0 will be using
> apr_file_t and apr_socket_t types.  Yes, downstream modules are going to
> take a hit, and so will all of the code in the base distribution.  But the
> argument for doing it is to get platform independance in Apache.

You keep using that argument, and I keep thinking it is bogus.

Yes, things will change, but why throw EVEN MORE changes at the person?
Geez. Should we also rename the request_rec fields? Hey, why not... they
have to recode their module anyhow. Oh... how about the #defines such as
HTTP_METHOD_NOT_ALLOWED? Those should start with AP_, right? Let's
change those, too! And OK, DONE, and DECLINED while we're at it!

Of course those are silly, extreme suggestions, but it is an example of
your logic taken to the next step.

While people will need to change certain things about their modules, we
should not gratuitously heap another bulk of changes on them just
because we can.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Mime
View raw message