At 01:27 AM 9/14/2002, Mladen Turk wrote:
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > 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
