The Cache class set the standard on how an formal adapter based class inside the framework looks like. Catalog already shares much of this formalism. Currently Logger, Auth and Session do not. We want to bring these classes on par with Cache. This will again bring us closer to homogeneous API design (for which the framework is well know for) and enable us to make changes to adapter based classes later easily in one go.
- make specifying the configuration name a requirement
- all methods take the configuration name as first parameter
- when needed, classes may support true for name to operate on all configurations (see Catalog::read())
- adapter methods should not return an implementation closure but simply execute immediately
- per adapter filters are not supported anymore, instead the manager class’ methods should be filtered
- abstract base Adapter class exists (see storage\cache\Adapter) and all class adapters inherit from it. This make creating adapters in userland a lot easier, as the base class is the documentation for which methods to implement.
- Session to support multi-key operations for read/write/delete (see Cache)
The Cache class set the standard on how an formal adapter based class inside the framework looks like. Catalog already shares much of this formalism. Currently Logger, Auth and Session do not. We want to bring these classes on par with Cache. This will again bring us closer to homogeneous API design (for which the framework is well know for) and enable us to make changes to adapter based classes later easily in one go.