On Thu, May 7, 2009 at 11:25 AM, Greg Knaddison <greg.knaddison@gmail.com>wrote:
On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Thu, 7 May 2009 09:23:48 -0500 Jeff Eaton <jeff@viapositiva.net> wrote:
Crell's Law: If an API must be use-case-optimized, make it swappable & tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations. APIs with one test case are rarely flexible enough for the second.
If you want to make stuff swappable start at least with 3 implementations otherwise 2 will just be a special case of 1.
We have to temper the ideal with reality. We have several swappable systems in Drupal (database, mail sending, caching, others?) and as far as I know only one of them has multiple backends in core (databases). We are able to have multiple backend for databases, but it takes a lot of effort. I doubt we have the capacity to create not just 2, but 3 implementations for all of the other swappable items in core. There's also the question of baggage. Do we really want to merge SMTP [1] and Fastpath FSCache[2] into core? Would that be a total improvement? Would the additional complexity (usability decrease) be worth it just so we can satisfy a desire to properly test that APIs?
Moreover, The whole idea of making it swappable is to avoid hacking core (and killing kittens) yet be able to customize things in new ways, without being limited by core's strict process and patch cycle. Experimentation is much easier with swappables in contrib. "Never underestimate the power of contrib ..." -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci