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
