> >
> >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:
apr_dbm_register()
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 :).
-Sterling
