apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/dbm/sdbm sdbm.c
Date Sun, 21 Jan 2001 01:54:28 GMT
On Sat, Jan 20, 2001 at 04:49:57PM -0600, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> > 
> > [ but most code can't be flexible ]
> 
> Then it isn't written to be portable.  apr is meaningless to such an app.

That is a silly position to take.

If I ask for the size of a file because I need it, and APR doesn't give it
to me, then that is an error. If I tell APR that I can be flexible, and can
somehow manage without it (because I've written extra code), then great.

APR needs to give me what I ask for, if it can. Whether that makes me
portable or not is NOT up to APR to decide.

APR defines a policy where it can refuse to return data, and it will advise
me of such. But I should not have to code a bazillion workarounds in the
common case. If I ask for something, and it doesn't come back: that is an
error. The code looks like:

    if (apr_getfileinfo(...) != APR_SUCCESS)
        /* ### error */

If I want to make my app flexible in what it can use, and what it can safely
NOT receive from APR, then I have that choice. But recognize that it
requires *extra* programming on the app's part to be flexible.

In the current scheme, I need extra programming for all cases:

  1) to deal with the case of APR_SUCCESS and some needed data isn't present
  2) to properly deal with missing data (when that is okay)

I'd rather see extra programming only for the "I'm flexible" case. That also
returns the semantics of apr_stat() to the original model.

Cheers,
-g

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

Mime
View raw message