[development] node caching

[Jeff Eaton]

I don't want to spend much time discussing the node caching issue, as  
I've already weighed in. But there have been a number of responses  
that suggested I need to produce a list of 'broken modules' or  
suggestions that I'm FUDding the addition of caching. I'd like to  
explain in a bit of detail what my concerns are; if they're solved,  
so be it. If not, well, same deal. I just want to make sure that  
these issues are raised.

There are a number of modules that it will definitely complicate  
things for (they'll have to learn a new way of managing data to avoid  
strange unpredictable 'stale data' bugs, and it ISN'T simply a matter  
of moving to view() operations on any sufficiently complex system).  
Obviously, developers can simply be told, "change your code, it's  
different now."

My biggest concerns and frustrations are based on two things:

1) Judging from the issue itself, it went in without considering the  
impact on sites where high interactive traffic (voting on nodes, etc)  
would frequently reset cached nodes. In these situations, caching  
could easily make things WORSE, as nodes will rapidly be loaded,  
cached and cleared rather than simply loaded.

The use of a 'nocache' param is certainly one solution, but it's an  
after-the-fact fix; it becomes the new, subtle, strange version of  
advanced caching's hook_init warning. "If you see something strange,  
maybe it's node caching."

2) It breaks existing APIs more than a month after the code freeze,  
__in a way that is NOT required to fix a critical bug__. It enhances  
performance in many cases, yes. But so would many API-breaking  
changes. I would have no problem with simply telling contrib authors  
to move their code to another op __if we were not past freeze.__ I've  
even argued for the addition of __non-breaking__ functionality post- 
freeze. But stopping breaking changes from coming in at the last  
minute is PRECISELY what the freeze is supposed to do.

Do I think that the feature is fundamentally flawed? NO. Do I think  
that it went in without sufficient consideration of the varied  
activity footprints of high-traffic production sites? YES. I've said  
my piece, and I don't plan on dwelling any more on the issue. If  
others feel it's important (Morbus and Crell are two who've spoken up  
with concerns) they can do so. There are other important things to  
work on and I don't want to end up spending my cycles going back and  
forth on this particular one.

If Dries and Goba decide to keep it and the concerns of others  
affected by it are quelled, so be it. I do think, though, that our  
very loose definition of code freeze (no breaking API changes unless  
required to fix a critical bug) should be revised. It should mean  
SOMETHING other than 'we think we're probably done breaking things,  
unless we come up with something cool.'

--Jeff