apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: apr_dbd API ideas
Date Tue, 22 Feb 2005 10:56:24 GMT
Edward Rudd wrote:
> I'm finally starting to hack away at Nick's new DBD API for APR, and have
> noticed a few things about the API, which I have talked with Nick about on
> IRC. And would like the thoughts of others.
> 
> One is a capabilities function in the driver API, to provide a way for the
> application to figure out what features the driver does and does not
> support. (ie. Transactions, Prepared Queries, etc..).

Agreed.

I made a conscious decision not to add that to the API before it went
under SVN: basically once it had reached "works well for me" and was a
candidate for inclusion, keeping it stable became the priority.  That
no longer applies:-)

> The other thing I noticed was the lack of standardized return codes from
> the functions.

Again, agreed.  I'm not quite sure what the procedure is for introducing
new APR error codes, but ideally we should do that.

> Right now I am hacking with the autoconf to get the DBD drivers to link as
> optional shared objects.

That really is great!  I've been struggling with TFM autoconf myself,
and the best I've done so far is more-or-less verbatim copying of
existing code.  Clues especially welcome in this area:-)

One more point here: for DSO loading of drivers, we could perhaps use
a "magic" versioning number.  Making that APR-wide would make sense,
preparing the ground for possible APR module support in other areas.
Any thoughts?

-- 
Nick Kew

Mime
View raw message