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. 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. Secondly, the only use case, that current OO save handler design is useful, is read()/write() override to encrypt/validate session data. Thirdly, I fixed _many_ of current OO API bugs, but fixing them all is impossible by design. 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? > 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. The RFC allows to save session data in whatever format. e.g. XML/JSON/BSON/etc. This is _impossible_ by save handler submodule. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
