Way, way, way back in January 2005 I was asked to take over as maintainer of Auth_PrefManager. I was actively using it and providing fixes for it and what little time the current maintainer had was being spent on Auth_PrefManager2. In fact it was originally why I got a PEAR developer account setup. I sent off my response accepting it and that was the last anyone heard from the previous maintainer as far as I can tell.
Fast forward two and a half year’s and Greg Beaver marked a crap load of extremely inactive (haven’t logged in in years) as inactive and thus their packages as unmaintained. So feeling bored (ie at work on a Monday afternoon and not really feeling like being productive) I loaded up PEAR’s Unmaintained packages page to see if anything I use had turned up with the latest changes. Unsurprisingly Auth_PrefManager and Auth_PrefManager2 where on the list. So I figured I’ve volunteered once before to maintain ‘em why not doing again.
After the usual bouncing of messages back and forth with PEAR QA and PEAR Group I got access and have spent the last couple of days sorting out the customised branch of Auth_PrefManager we use here so that it can be released as Auth_PrefManager 1.2.0.
So what can one expect from this new release? Well not really much of anything in the way of new features, it’ll still be PEAR DB only, it’ll still be PHP4 code and it’ll still be fairly lightweight. What it will have is the following:
- PEAR Error Handling. To maintain backward compatibility you will have to manually switch on PEAR Error handling but when you do things like database connection failures and mis-typed field names will return a PEAR_Error object instead of the same value returned to indicate that preference doesn’t exist.
- Delayed Database Connection. No more connecting to the database in the object constructor and if it failed attempting to return an error object or a boolean from it. This means yes its possible to actually detect when the database connection fails.
- Removal of a huge chunk of redundant code.
- Checks that the database connection is actually present before attempting to query it.
- Unit Testing.
So yeah nothing really amazing in there just making the bloody code work and stay working for the foreseeable future.
As to Auth_PrefManager2, well I haven’t really had a good look at it yet but the basic ideas are to remain the same. Multiple backends for storing preferences. Singleton and Factory access methods. Where I’m likely to deviate from whats already done is to make it PHP5 code (it was started long before PHP5 became the direction for PEAR) and likely more integration with Auth2. Likely the Auth2 integration will come more from the Auth2 side where with a single option you can turn on Auth_PrefManager2 as part of the Auth2 object. Something like
$auth2->getPref('foo')
returns the ‘foo’ preference for the currently logged in user.
