On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan <dar...@darrenduncan.net> wrote: >> How mandatory, currently, is the "mandatory shared codebase?" Are >> there really traps and snares preventing >> a different framework from using DBD modules? I'm presuming that there >> aren't; ICBW.
> So getting away from the "framework" mentality is the point here. I've got the idea (and also the feeling that carrying on this discussion on-list is dubious; but I think I might speak for others) that your proposal is a change in one's way of looking at the architecture, rather than a proposal for a change to the DBI. A lot of other framework/module projects exist: firefox and qpsmtpd are but the first examples that come to mind. Sometimes another framework can replace the core, and plugins can be reused -- I think but am not certain that chrome can handle some firefox plugins without modification. I've often wanted to formalize the qpsmtpd plugin interface to the point where a different MTA could use qpsmtpd plugins unchaged, but haven't found the time for that. Actually the big SMTP plugin framework is "milter" which is defined as a clean interface to the point where other MTAs offer Milter interfaces. Are you asking for something beyond documenting the DBI/DBD interface to the point where a DBD can be used more directly than through the DBI? Aside from requesting that everyone abandon the framework mentality? Are you asking for a stronger set of conventions in DBDs that will make them more useful away from DBI? Are you proposing to write thinner glue?
