[development] Proposed Apocrypha

[Jeff Eaton]

On May 7, 2009, at 10:25 AM, Greg Knaddison wrote:

> 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?

Also, the rules and corollaries I'm brainstorming are limited by the  
fact that I'm trying to fit them into Twitter-compatible 140-character  
snippets. It's a nice exercise in simplicity when explaining  
principles can easily veer into long digressions. ;-)

I agree that three implementations is better, because we're more  
likely to run into REAL variations, but as you say it's not  
necessarily realistic that very new API have three fully fleshed out  
example implementations. We can work towards it, and encourage it, but  
it's the "only one implementation" scenario that should really set off  
warning lights when we see it. The "write two" is mostly about smoke- 
testing for 'fake APIs' that look like swappable subsystems but are  
still too anchored to the original implementation to be replaceable.

Also, I don't think we necessarily HAVE to include each of our test  
implementations in core. But we should at least write them whenever  
possible, to flush out problems and also to reveal areas where  
'perfect flexibility' isn't worth the overhead. (A persistence layer  
that can use SQL databases or XML files would be terribly flexible but  
probably not worth the work, for example.)

-eaton