> 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?

Reply via email to