On Fri, Dec 08, 2000 at 12:29:47PM -0600, William A. Rowe, Jr. wrote: > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Friday, December 08, 2000 11:31 AM > > > > > Log: > > > Document and address several problems with apr_dbm - including; > > > > > > make apr_dbm_open args sane in respect to both apr and dbm > > > note absurdity of apr_dbm_freedatum in a pool-managed > > > implementation > > > note obscurity of apr_dbm_geterror in relation to apr > > > > I would just like to go on record as saying that the dbm portion is the > > incorrect solution. PHP has already solved this exact problem in a > > portable way for far more databases.
You're referring to the "dba" code in PHP4. I've looked at it quite a bit when I set up aputil/apu_dbm.c, to see how theirs compared to what I had already set up in mod_dav 1.0 (which is where apu_dbm's code came from). > > Why are we duplicating their work? There isn't an intent to duplicate their work, but it does happen to be because: 1) their code is designed to be integrated into PHP rather than as a separable library 2) it does not use pools 3) it does not support SDBM 4) it does not have the freedatum or geterror calls (in fact, I see their GDBM code does a printf() for one of the error cases!) 5) this code is total cake. there isn't any true leverage (in terms of maintenance) by trying to use their code. We support SDBM and GDBM. They support CDB, DB2, DB3, DBM, GDBM, NDBM. > > Their license is completely compatible with ours, so > > we should just be able to take their code and move on. Well, there are acknowledgement clauses and things that we would then need to incorporate. Compatible, yes. Easy? > In leiu of or in addition to sdbm, fine. But in terms of a pool memory > wrapper > for dbm access, that still has a benefit. Right. > We [should] eliminate (or shield) the freedatum in the retrieve call, copying > the datum into the pool. The user frees the pool and all goes away. > Advantages > include the fact that the datum is modifiable in-place, and persist after the > database is closed (if this behavior is desired, as it may be in Apache or > other > threaded pool-based applications.) The user can make the copy into the pool if they desire. We should not be adding that overhead unilaterally. However! We should register a cleanup in the GDBM case, and put a note in the doc about the duration of the datum's contents. I just never got to the former, and didn't think about the latter until this discussion. There is also one more entry point that we need in the API (to discover the file names used, so that a caller can delete/rename/move them if desired). >... > One last observation, sdbm.h does _not_ belong in apr-util/include/ and > neither > does the apu_private stuff. Suggest we move those on out of there, but where? > apr-util/include/private? We don't need arch/ anything, since headers > shouldn't > change the same way in apr-util (it's already cross-platform, right :-?) We could move apu_private to a subdirectory, but why? A handy subdir was available in APR, so that was an easy choice to hide the include file. I say that we leave the file and simply tell people "you're an adult. listen to us when we say don't include it." > Note we don't appear to have an apr-util.h just yet for compiled-in features > of the lib... we need one, no? if/when we have separable features. Cheers, -g -- Greg Stein, http://www.lyra.org/
