apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Mutli-DBM patch
Date Thu, 29 Nov 2001 22:07:51 GMT
On Wed, Nov 28, 2001 at 08:03:38AM -0800, Ian Holsman wrote:
> Jeff Trawick wrote:
> > As far as autoconf usage, it looks reasonable to me...
> > 
> > Any reason why the type parameter passed to the new open function is
> > char * instead of an enum?
> > 
> > Is there a way for apps to be aware of the APU_HAVE_foo capabilities?
> I guess..
> we just need to move the #defines somewhere they can see them maybe apu.h.in
> instead of _select_db.h


> > (I don't think this has to be solved immediately.)  Some will want to
> > know what choices they should offer their users.  
> how about a function which returns a array of choices?
> > I guess having a char * type lets the app pass it straight from a
> > configuration directive to apr-util with no knowledge on the part of
> > the app.
> yes..
> the plan in the future would be to add a hook or something at the end of the function
> so other DBM's can register themselves and let them handle the open call.

I think that internally, we want a hash table of names to vtables. Note that
the names in the vtables are lower-cased. In the patch, I think you should
use lower-cased names.

Further, I'd say that symbolic constants should be created:

#define APR_DBM_OPEN_SDBM "sdbm"
#define APR_DBM_OPEN_GDBM "gdbm"

Also, the configure logic for sdbm and the various symbols aren't needed. We
always have it, so you can simplify a lot of stuff by omitting all that

In your post, you mentioned something about openers for each dbm. I'm not
sure why... that doesn't seem all that useful?


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

View raw message