Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020914111849.01eff130@pop3.rowe-clan.net>
Date: Sat, 14 Sep 2002 11:24:24 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: RE: Flat File APIs [was Fixed htpasswd?]
Cc: dev@apr.apache.org
In-Reply-To: <002001c25bb7$d1640110$5c00000a@GISDATA.ZG>
References: <5.1.0.14.2.20020913224553.0281b4a8@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:27 AM 9/14/2002, Mladen Turk wrote:

> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> >
> > That wasn't all that was borked here.  This file is a total
> > mess, and needs to be entirely refactored.  We are trapping
> > on situations that are not errors and shouldn't be expected
> > to work (fail to open a non existant file for append?  Duh.)
> > And we entirely fail to look for errors and report them when
> > we should.  The Apache project put its name behind this code?  Bleck.
>
>Year or so ago I've make a complete rewrite of the htpasswd that
>remained the logic, but then "someone" told me that this is too much
>"changes" at once and that people cannot follow the code difference.
>Nice to see that the winds are changing :).

Actually, this file has only changed incrementally.  Sometimes, however,
incremental changes become very difficult to follow, that's when a bit
of refactoring is appropriate.

However, if you can keep each patch of the refactoring somewhat small-ish
it is still easier to follow that a total rewrite :-)

>Now I'm proposing (like I did a year ago) that we build an
>infrastructure that can be put in the apr_util or kept in httpd that
>will all the auth utilities use for managing password
>files/databases/etc...
>The current htpasswd, htdigest and htdbm utils will then become only the
>user interface to that code base, and all that is needed is a decent API.

And this time around, I believe you have more support, given that the
aaa logic is now refactored.  Both the consumer {modules/aaa} and the
producer {htutils, etc} would benefit.

It's pretty obvious that a robust flat-file-modification API would be good,
since we already have the dbm file API.  Had every utility not rolled their
own, these problems wouldn't strike in odd places ;-)

And yes, I believe that discussion would be good for apr-util.

Bill