I'm finally going to work on caching in OpenInteract. It's always been hanging out in the background, threatening to be implemented. But it's always been neglected -- not enough tuits, no reason, etc.
Now that I've been updating my site on a fairly frequent basis, I've got a decent testbed for development. If it doesn't work at first nobody will lose their job and it's easy for me to see whether it's working. (I don't really need caching, but then I don't really need a personal website either.)
This will be easy and transparent in OI 2 since actions will actually carry state around with them, and instead of calling the content generator directory they'll call 'generate_content()' which will call the deployed content generator for the action. (This should allow for SOAP, etc.) But for OI 1 this is more difficult: content handlers are class methods, so we have the kludgy hashref being passed around everywhere. But I think I should be able to modify a single class -- which most handlers use and derive from -- and allow caching with fairly small modifications to the handlers themselves. More as implementation progresses...
It's a messy problem.
Re:the tough part of caching...
lachoy on 2002-09-06T01:24:36
...which is another (very big) reason why I've waited so long to deal with it
;-) This is why starting simple is good. In OpenInteract the same type of data is usually displayed and modified in the same class, so having one action expire the cache for another isn't too hairy. Once we get beyond that, we'll just have to see -- this will likely be a 'caveat hackor' sort of thing, since creating generic tools to deal with expiration isn't too appealing. (Lots of effort for questionable payoff.)
