On Mon, Dec 5, 2016 at 4:31 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Marco, > > Thank you for explaining the reason why! > > On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta <ocram...@gmail.com> wrote: > > I voted "no" because I don't see any advantage over using a custom > session > > save handler, besides adding more API that partially covers custom > session > > save handlers. > > You mean current OO custom save handler, I suppose. > Yes > Firstly, current OO custom save handler design (use of previously used > internal save handler as its base class) is not good. Overriding > open()/close()/etc are useless, moreover harmful. Number of bugs > proved it is not good. > Number of bugs? In which adapters? There are well tested session savehandlers out there, and I'd trade a userland bug for an internals bug anytime. > Secondly, the only use case, that current OO save handler design is > useful, is read()/write() override to encrypt/validate session data. > What does this RFC do that a custom session savehandler *CANNOT*? > Thirdly, I fixed _many_ of current OO API bugs, but fixing them all is > impossible by design. > It would need a deprecation of the current session module, and a replacement with a newer, cleaner API. > Current OO save handler API is wrong in many ways and should be > deprecated and replaced by clean OO API as mentioned in the RFC. > > Is there any good reasons to keep problematic API for good? > There is a problem with adding a half-feature to fix half the problem, and then having to deprecate this half-feature when the new full solution is actually replacing it in a correct way. > > This is just confusing, in my opinion, and the API can be replicated in > > userland with a custom session save handler decorator instead. > > I may be too familiar to session module. I don't understand what's > confusing. Session module has 2 distinct submodules for saving and > serializing data. These have different tasks. > It is confusing that we now have two ways of passing down serializers for sessions. The Redis session savehandlers already use igbinary where applicable, for example, so why do I need to have a second equivalent API? Providing a userland base session savehandler with pluggable serializers (written in PHP, not in C, please!) is a much better idea. The RFC allows to save session data in whatever format. e.g. > XML/JSON/BSON/etc. This is _impossible_ by save handler submodule Savehandlers even save to flat DB tables, so I'm not understanding what is being explained here... Even in the docs, the first example shows how to add encryption to a custom savehandler: https://secure.php.net/manual/en/class.sessionhandler.php Adding a custom serialization is as simple as an `unserialize()` + custom serializer call (Yes, I can already hear all those microseconds screaming! The horror!) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
