Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <004b01bf9feb$85c626f0$c1e01b09@raleigh.ibm.com>
From: "Bill Stoddard" <stoddard@raleigh.ibm.com>
To: <new-httpd@apache.org>
References: <Pine.LNX.4.10.10004061301090.19191-100000@shell.ntrnet.net>
Subject: Re: concerns about the recent error checking added to APR
Date: Thu, 6 Apr 2000 13:14:09 -0400
Organization: IBM Corp.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


>
> > I agree with Jeff on this one. Better to fail in an obvious and
noticable
> > way (a segfault).  IMHO, APR should trust the application developer to
use
> > the APIs correctly.  Otherwise you gorp up the code with all sorts of
> > trivial error checking.  If the application doesn't use the API
correctly,
> > then it 'deserves what it gets' :-). Okay, I will make a generalization
and
> > like most generalizations, it doesn't always apply...   You should not
add
> > error checking to detect programming errors within the scope of the code
you
> > have access to and control (and can change). In other words, Apache and
APR
> > should trust the other to do the right thing.
>
> But, APR has always had plans to spin off from Apache.  So the question
> remains, do we provide the error checking when APR is not a part of
> Apache.  BTW, the argument that Apache is APR's only client no longer
> holds water with me.  I had three separate people walk up to me at
> ApacheCon and tell me they had plans to port their apps to APR.
>
> Note, I am playing devil's advocate here, because I am still very torn on
> this whole issue.

APR will always be open source as will be its applications (at least the
ones we care about :-). So the argument applies even when APR becomes a
standalone ASF project.

Bill