apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sterling Hughes <sterl...@designmultimedia.com>
Subject Re: [proposal] DBM - allow multiple DBM's of differnt types at the same time.
Date Mon, 20 Aug 2001 20:07:14 GMT
> >
> >Well, I think we should choose one, and just follow that one model.  I personally
> >would rather use an argument to specify the type.  We can't do that with buckets,
> >because that would require function overloading.  SMS should move to just
> >a simple argument IMHO though.
> >
> the problem passing a option to the dbm open is twofold.
> 1. If I want to add another dbm  (say NuSQL's genesis or some comerical
> package) I would then need to
> modify apr-util and add the flag. this means a branch and will present a
> road block for me upgrading apr-util

	Not sure I understand what you're saying?  There are ways to allow
	the registering of module functionality, without modifying the main
	package.  Just provide a function like:


	Which registers a dbm internally, and then have a constant defined
	in a seperate file, and all is clear...

> 2. I may have a dbm which needs extra parameters to open it. (say for
> exampe cache size, or maybe it requires
>     a fixed key length defined) I couldn't do this simply

	dbm_set_x() and check the flags, once they're all filled out (a
	va_args implementation could also be done...)

	Furthermore, the idea of an abstraction layer is too bring all these
	down to a lowest common denominator, at the cost of functionality
	sometimes; usually functions that take extra arguments, can be
	filled in with acceptable defaults.  You'll run into the same
	problems in that some db's don't support certain features, and
	others do, the idea is to concentrate on the functionality that is
	necessary and shared between the different db's (wrap this in a
	large imho :).


View raw message