General developer forum

Hi Ryan,
you could take a look at MDL-37069 to have a reference about two examples of implemeting the same cache stores using XCache: you'll find some answers and some of your questions too.
Sam Hemelryk is The Master in this area being the architect/owner of all the MUC related stuff: I'll try to give you some replies from what is my coding experience - and you'll see in my XCache store that sometimes I've taken choices different from what coded by Sam with his XCache implementation so I could be wrong .

1. IMHO MODE_REQUEST should be excluded, MODE_SESSION should be added if you think that the persistence offered by the cache service can be easily managed to purge the values when the user session will be closed. AFAIK, at the time of this post, the MUC framework doesn't do that and you are required to define a TTL outside the MUC code if you want to be conservative about "size vs hit ratio" because MODE_SESSION data have by nature a limited life time and you want those data to be flushed to free space for more persistent data (MODE_APPLICATION);
2. SUPPORTS_*:
   1. SUPPORTS_MULTIPLE_IDENTIFIERS: read the explanation in https://github.com/moodle/moodle/tree/master/cache#store
   2. Awareness: it's up to you to implement the cache_is_key_aware interface in your WinCache store plugin if you have the support from its own API (e.g.: XCache has xcache_isset())
   3. SUPPORTS_DATA_GUARANTEE: the second, TTL should not be IMHO configured if you want to offer such support. Beware that regardless the Moodle configuration in the Cache Definition your sysad could have configured TTL at WinCache level, if possible, so the store should come with a README file explaining how the different configuration parameters at the sysad level could impact on the way the store will work in Moodle
3. Look at the configuration of WinCache to look at what parameters should be configured by the sysad and then carefully configured in terms of what (average?) numbers to put some blocking conditions e.g. to enable the WinCache store or to add SUPPORTS_DATA_GUARANTEE

I'll review my code, to help us (you and me) in coding the "perfect" store plugin .

HTH,
Matteo

Hi guys,

Worth noting is that Ryan has created MDL-38987. If anyone arrives here and would like to see a WinCache plugin created please visit that issue and vote to support it.

In regards to the questions you have asked Ryan I think the answers Matteo has given a pretty much spot on.
If you've any questions don't hesitate to ask them here in the forums or on the noted issue.
No doubt Matteo or myself will be able to help you.

Many thanks
Sam

Great, thanks for the input! I've almost completed the WinCache plugin, just need to finish the README. Couple more questions though;

1. Just to clarify, and from what I could tell, there technically no programmical differences between the different supported modes? So the supported modes is just a guideline for which the cache store would be a good fit for?
2. Why would the REQUEST mode not be a good fit for WinCache/APC/xCache/etc.? It appears that APPLICATION is really the best option. SESSION can actually be handled by the session store and enabling WinCache to handle session (which I'll mention in the documentation).
3. Should I create the tests/wincache_test.php file? I notice they exist in Moodle core cache store plugins however I didn't see them in your xcache and apc plugins.
4. WinCache supports locking, should I implement cache_is_lockable? Not hard to do but the WinCache documentation says it could create deadlocks in PHP (naturally).

WinCache also has a statistics page, similar to [Site Admin > Server > PHP info]. I'd like to add that as a plugin (as I'm sure it wouldn't be included into core). Where would the best place be to add those files? I'll also need to add a link to the admin menu, so settings.php needs to be read. Thanks!