by Martín Langhoff.
Thanks for the reference!
I followed the link and the context is a bit wider in a historical sense. It seems to talk about the earlier roles implementation as an initial "wrong" implementation. I would call it a pretty good 80% implementation![smile]( "smile")
-- which in software still means that you have to stretch out and cover 100% (or at least 99%), as Joel writes here http://www.joelonsoftware.com/articles/fog0000000020.html
My initial reading of the quote made me think of the roles implementation we had in 1.7 and 1.8 which just "worked" for small values of "worked".
Would I had done the same? I don't know. At a technical level, of course I wanted a different approach, and I implemented it when I found the opportunity (and that was much, much later). The challenge was in getting roles done in time for v1.7 -- and on that front MD and the team took a practical approach and shipped. And that's how you get software done.
I do think there was a missstep in late v1.7 dev and 1.8 -- I could perceive it at the time but I could not help; in fact I could not even articulate the concept clearly. Now I can. Naive caching systems don't work very well with PHP because the engine is stateless. So caches are actuall expensive. This raises the bar significantly -- only very well designed caches give you a worthwhile payoff.
So IMHO the MUC is too simple and is hurting us. Plenty of stuff on my plate at Remote-Learner right now, but I am trying hard to find the opportunity to dig into this and put numbers, traces and patches behind my words.
To refine on the concept: in PHP, there is not static memory that persists between queries, this makes caches (relatively) expensive to read. When code is thrashing the DB with lots of small queries, I first go looking at reworking the code a bit to be nicer to the DB, and only afterwards then at designing "small and beautiful" caches, crafted for the specific use case and _measured_ to give you payoff.
Moodle probably only needs three or four cache implementations, and then careful pairing of cache to task. However... to put that specialized cache to work for a module you do have to rework the code. So it is a lot more work than a generic caching layer.
I followed the link and the context is a bit wider in a historical sense. It seems to talk about the earlier roles implementation as an initial "wrong" implementation. I would call it a pretty good 80% implementation
My initial reading of the quote made me think of the roles implementation we had in 1.7 and 1.8 which just "worked" for small values of "worked".
Would I had done the same? I don't know. At a technical level, of course I wanted a different approach, and I implemented it when I found the opportunity (and that was much, much later). The challenge was in getting roles done in time for v1.7 -- and on that front MD and the team took a practical approach and shipped. And that's how you get software done.
I do think there was a missstep in late v1.7 dev and 1.8 -- I could perceive it at the time but I could not help; in fact I could not even articulate the concept clearly. Now I can. Naive caching systems don't work very well with PHP because the engine is stateless. So caches are actuall expensive. This raises the bar significantly -- only very well designed caches give you a worthwhile payoff.
So IMHO the MUC is too simple and is hurting us. Plenty of stuff on my plate at Remote-Learner right now, but I am trying hard to find the opportunity to dig into this and put numbers, traces and patches behind my words.
To refine on the concept: in PHP, there is not static memory that persists between queries, this makes caches (relatively) expensive to read. When code is thrashing the DB with lots of small queries, I first go looking at reworking the code a bit to be nicer to the DB, and only afterwards then at designing "small and beautiful" caches, crafted for the specific use case and _measured_ to give you payoff.
Moodle probably only needs three or four cache implementations, and then careful pairing of cache to task. However... to put that specialized cache to work for a module you do have to rework the code. So it is a lot more work than a generic caching layer.