Re: [RFC][VOTE] User defined session serializer

> Am 07.12.2016 um 21:07 schrieb Yasuo Ohgaki <yohgaki@ohgaki.net>: > > Hi Tony, > > On Wed, Dec 7, 2016 at 7:17 PM, Tony Marston <TonyMarston@hotmail.com > <mailto:TonyMarston@hotmail.com>> wrote: >> "Yasuo Ohgaki" wrote in message >> >> news:CAGa2bXYaX05JbJAvyxfSJyy6xiA+4u14NPFGYwScL4aoOFQGhw@mail.gmail.com... >>> >>> >>> Hi Marco, >>> >>> Thank you for explaining the reason why! >>> >>> On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta <ocramius@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. >> >> >> I have been using session_set_save_handler() since 2002 to store all session >> data in a database, and I have never encountered any problems. Why is it >> "not good"? What bugs are there? > > It works if it is used correctly. However, we've got number of bug > reports for abuse/misuse cases. Refer to bugs.php.net <��֚c��� > �"��http://bugs.php.net/> for details. > >> >> I do not see the point in this RFC. > > Did you read the RFC? > It enables to write serializer by PHP script, clean and simple. It > cannot be done by save handler. We can just directly read from $_SESSION (in write) and use session_encode() (for returning on read()) as a workaround. It isn't the cleanest way, but it works. I appreciate a cleaner way, but it really should (see the last mail) cover everything, including the need to store to different locations. > Besides, the reason why we don't have user defined serializer is > "register_globals", the reason why we have problematic base class for > OO API save handler is "register_globals". We should get rid of > obsolete features at some point also. Could you please that explain further? Also cleaning up obsolete features would be nice, rather sooner than later. Bob > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > <http://www.php.net/unsub.php>