Feature #6426
Implement caching backend for other opcode caches.
| Status: | Closed | Start date: | 2010-02-10 | |
|---|---|---|---|---|
| Priority: | Won't have this time | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Cache | |||
| Target version: | - | |||
| PHP Version: | Complexity: | |||
| Has patch: |
Description
Currently the flow3 caching backend as well as its typo3 backport support the APC opcode cache.
Other populare opcode caches e.g. xcache, eaccelerator also offer the the oportunity to store data the shm.
Since the shm storing api accross different opcode caches just varies a little (mainly naming of put/get functions) it might make sense to create a seperated abstract "opcode cache backend" class and let the actual opcode code cache specific backend inherited from it.
I attached very a rough (and not fully tested) xcache caching backend class i put together by copy and pasting from the typo3 apc cache back end. Just to illustrated the minor difference.
History
#1 Updated by Karsten Dambekalns over 5 years ago
- Priority changed from Should have to Could have
Well, alongside APC we support memcache. eaccelerator did not work with PHP 5.3 anyway last time I checked, has this changed? xcache is new to me, IIRC...
#2 Updated by Nikolas Hagelstein over 5 years ago
Karsten Dambekalns wrote:
Well, alongside APC we support memcache. eaccelerator did not work with PHP 5.3 anyway last time I checked, has this changed? xcache is new to me, IIRC...
eAccelerator 0.9.6 claims to work with php 5.3 but i haven't tested it yet.
#3 Updated by Robert Lemke about 5 years ago
- Status changed from New to Closed
- Priority changed from Could have to Won't have this time
In general, there's nothing wrong with supporting more caches. But at this time it has a too low priority for the FLOW3 / TYPO3 Phoenix development to let it in. At this point I could only accept a fully functional, clean and tested implementation - we can't handle less than that at the moment.