> 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. Why are we duplicating their > work? Their license is completely compatible with ours, so > we should just be able to take their code and move on.
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. 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.) It would be cool to simplify apr_dbm to leverage PHP's abstraction, however :-) I'm not investing any more time in apr_dbm until we hash these questions out, however. 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 :-?) Note we don't appear to have an apr-util.h just yet for compiled-in features of the lib... we need one, no?
