On Tue, Oct 26, 2004 at 07:32:29PM -0400, Christopher Hicks wrote: > On Tue, 26 Oct 2004, _brian_d_foy wrote: > >In article <[EMAIL PROTECTED]>, Smylers > ><[EMAIL PROTECTED]> wrote: > >>I think the opposite -- that DBIx:: should be for things that are > >>generally usable with DBI, where the "I" is independent. Things such as > >>backing up tend not to be database-independent. > > > >if we work it right, DBIx::Backup could be independent, while > >DBIx::Backup::MySQL implements the MySQL bits. :) > > Exactly. If DBIx::Backup::MySQL has a clean interface it might even > inspire a generic DBIx::Backup and become the MySQL implementation of > DBIx::Backup and spark a revolution in database administration. :)
DBIx isn't for this kind of thing (frameworks of modules working together). Modules are generally be named for what they do not how they do it. So DBIx in a name is only appropriate when the "what it does" is closely tied to the DBI. If anyone wants to start a database independant backup project, using 'plug in' modules for different databases, then they ought to use a new top-level namespace like DatabaseBackup::* Tim.
