Goal
As there are plenty of storage backends provided with laminas-cache, I would like to introduce satellite packages for each of them.
The same goes for plugins.
Background
Any cache backend has its own unit/integration tests. To test the compatibility, we have to enable/disable the tests so we do not have to wait ages for results if we changed a plugin for example. Furthermore, the compatbility of the storage backend is being checked during instantiation:
if (! extension_loaded('redis')) {
throw new Exception\ExtensionNotLoadedException("Redis extension is not loaded");
}
The same goes for the Serializer
plugin where the laminas-cache
composer.json
suggest installing laminas-serializer
to work properly.
The PluginOptions
contains options for all plugins. I would prefer having the same logic as with the StorageOptions
and let satellites extend the options if necessary.
satellite packages are the best way to solve all those issues:
- we can execute tests for the specific satellite package without enabling the unit tests within phpunit file
- we can set explicit package requirements with composer (starting with v3)
- we can archive/deprecate packages more easier if needed (for example, APC would be one of those we can archive as its abandoned since 2012)
Considerations
- Having multiple satellites might raise the need for more maintainers.
- Maintainability for 20+ new libraries might be awful.
- Creating template repositories for plugins and storages.
- Creating
laminas/laminas-cache-storage-implementation
virtual package (can be packed with thecomposer.json
of the template repository)
Suggested Approaches
satellites to create
I’ve thought about creating satellite packages for all storage adapter aswell as all plugins.
For the current version laminas-cache
2.9.0, we would end-up with the following satellites:
Storages
- Apc
- Apcu
- BlackHole
- Dba
- ExtMongoDb
- Filesystem
- Memcache
- Memcached
- Memory
- MongoDb
- Redis
- Session
- WinCache
- XCache
- ZendServerDisk
- ZendServerShm
Plugins
- ClearExpiredByFactor
- ExceptionHandler
- IgnoreUserAbort
- OptimizeByFactor
- Serializer
We could create template repositories for both storage- and plugin-satellites.
This would provide contributors an easy way to easily create either a storage backend for their own (as I did already with boesing/zend-cache-redis-cluster) and/or provide it to the laminas organization. Either way, having templated storage backends and/or plugins makes it easier for others to contribute to the laminas ecosystem even without sharing the code with the laminas organization at all.
Virtual package for storage backends
With v3, we could go with laminas/laminas-cache-storage-implementation
as a virtual package (like psr/container-implementation
) and thus, the migration process will force the user to choose at least one storage implementation as the laminas/laminas-cache
repository does not contain any storage anymore.
der
Alternatives
- Creating only satellites for those plugins/storages which require external dependencies and thus need “suggest” entry in the
composer.json
- Stay with a cache monorepo
Unresolved questions
- Should we create satellites for all plugins or just for those with dependencies?
- Do we need maintainers for each satellite?
- Can we already drop more storages than just
Apc
? - Should we create satellites and attach them to the current
laminas-cache
composer.json
and drop them with v3? - Namings for satellites?
- Storages?
-
laminas/laminas-cache-storage-*
e.g.laminas/laminas-cache-storage-redis
-
laminas/laminas-cache-*
e.g.laminas/laminas-cache-redis
-
laminas/laminas-cache-*-storage
e.g.laminas/laminas-cache-redis-storage
- other? Feel free to comment!
-
- Plugins?
-
laminas/laminas-cache-plugin-*
e.g.laminas/laminas-cache-plugin-serializer
-
laminas/laminas-cache-*
e.g.laminas/laminas-cache-serializer
-
laminas/laminas-cache-*-plugin
e.g.laminas/laminas-cache-serializer-plugin
- other? Feel free to comment!
-
- Storages?
- Should we go with
laminas/laminas-cache-storage-implementation
with v3?