On Mon, 2001-08-20 at 13:07, Sterling Hughes wrote: > > > > > >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... that would work, but that wouldn't that mean there would be need to some init code somewhere to call the registration function? > > > 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 :). >
true, thats why they all return the same thing (apr_dbm_t) the open_DBM function was supposed to be called when the devloper wanted to do something specific with this type of dbm. so in the berkley DB case there could be a apr_dbm_db_getRaw() function which returns the DB* so that developers are not constrained the set of functions we chose to abstract. (BTW I was planning on implmenting a shared-memory hash table, that I posted ages ago, via this DBM interface, and it required a different set of opening parameters (key/elem size, #elements) these parameters could be passed via a db_set function call but it would look clunky ..Ian so.. shall we put it to a vote? apr_dbm_open_XXX or apr_dbm_open(XXX) ? (I'm assuming that APR-Committers are happy that I go messing with dbm in the first place ;-) > -Sterling >
