[RFC]: Detach serializer plugin from `laminas-serializer`

[boesing]

RFC

Q	A
Proposed Version(s)	4.0.0
BC Break?	Yes

Goal

Decoupling the cache component from the serializer component.

Background

The serializer component is meant to be in feature-complete/security-only mode. The reason why we did that is, that one can simply use json_encode, serializer, etc. by himself.
I've never seen a project where serializers were replaced and even tho, changing a configuration file and/or changing the piece of code which does actually calls the serializer component is the same amount of work.
Since there won't be any feature additions to laminas-serializer anymore (maybe no update to PHP 8.2), removing actual support for laminas-serializer should be considered.

Considerations

Projects need to require at least the serializer satellite which provides the interface + the most basic serialization methods which do not need additional dependencies. Having a bridge for laminas-serializer which can be used together with older laminas-serializer versions might be an idea even tho I do not think that laminas-cache v4.0.0 will be compatible with laminas-serializer in its current version as of incompatibilities with minimum servicemanager version (v4.0.0).

Proposal(s)

Provide a satellite laminas-cache-serializer or laminas-cache-storage-plugin-serializer, implementing "basic" serialization methods (which do not depend on external dependencies) such as:

• Json
• PhpSerialize
• PhpCode (IMHO, this should be dropped as it uses eval to actually unserialize data which feels more than uncomfortable to me)

We could also create laminas-cache-storage-plugin-serializer-igbinary which also requires ext-igbinary could provide the current IgBinary serializer, maybe an laminas-cache-storage-plugin-serializer-msgpack, etc.

We should try to focus on those without additional need for extensions. We can create the other satellites once it is requested with careful consideration if we actually want to support that or - in case we won't - we can still provide ideas on how it could be implemented in client projects without the need of maintaining it on our end.

Appendix

namespace Laminas\Cache\Plugin\Serializer;

interface SerializerInterface
{
    public function serialize(mixed $value): string;

    public function unserialize(string $value): mixed;
}

Due to the different namespace, it should be possible for upstream projects to actually adapt the configuration in v3.0.0
The configuration schema should be changed to consume FQCN, i.e. Laminas\Cache\Plugin\Serializer\PhpSerialize::class to avoid the usage of aliases and stuff.

This is just a quick braindump which came to my mind. Not sure if we can already provide a bridge to laminas-serializer but I don't think that is necessary as the new plugins configuration will most likely only compatible with v4.0.0 of laminas-cache which would conflict with laminas-serializer due to laminas-servicemanager v4 requirement.

I would really love to get some feedback here, maybe with some other opinions, ideas, etc.
I am not doing this for myself since I mostly depend on the redis adapter which does already provide serialize, igbinary and msgpack on its own without the need for the serializer plugin. We do only use PhpSerialize for the filesystem adapter and thus, I don't bother too much with igbinary implementation until it is demanded.

[froschdesign]

Since there won't be any feature additions to laminas-serializer anymore (maybe no update to PHP 8.2)…

laminas-serializer supports version 8.2 of PHP or is something missing? Or do you mean 8.3?

…removing actual support for laminas-serializer should be considered.

If the support for laminas-serializer is removed here then the same must be done for laminas-hydrator:

https://docs.laminas.dev/laminas-hydrator/v4/strategies/serializable/

[boesing]

laminas-serializer supports version 8.2 of PHP or is something missing? Or do you mean 8.3?

oh yah, was referring to 8.3

If the support for laminas-serializer is removed here then the same must be done for laminas-hydrator:

pretty sure, yes. every component which is security only needs a new major and since there wont be a new major for serializer component due to security-only, this is the way. :-/

[froschdesign]

…since there wont be a new major for serializer component due to security-only…

Is this rule written down somewhere? Otherwise, break this rule if it is easier than opening and maintaining several satellite packages.

[boesing]

We revived laminas-serializer for now, therefore closing this until we have another need for this.