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

Yes.

> > (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"
etc.

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
logic.

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

Cheers,
-g

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

Mime
View raw message