Hi all, On Mon, Dec 5, 2016 at 10:44 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > This RFC exposes session serializer interface to user space. It works > like user defined session save handler. > > Users are able to encrypt/validate session data transparently. e.g. > You can save encrypted session data to database, decrypt encrypted > data from database transparently. > > https://wiki.php.net/rfc/user_defined_session_serializer > Vote starts: 2016-12-05 Vote ends: 2016-12-19 UTC 23:59:59 > > Although we don't have consensus about number of votes to pass, I set > this RFC to require 2/3 votes. > > Questions are welcomed if you have. > Thank you for voting.
This patch is simple register_globals legacy fix for me, i.e. If there wasn't register_globals, there would be user defined serializer already[1] Users cannot implement their own serialization clean and efficient way without this patch.[2] Vote is 9 in favor and 9 against currently. https://wiki.php.net/rfc/user_defined_session_serializer#proposed_voting_choices It is surprise for me that this many people against the RFC. bwoebi (bwoebi) danack (danack) hywan (hywan) leigh (leigh) levim (levim) nikic (nikic) ocramius (ocramius) peehaa (peehaa) ryat (ryat) Denial of this RFC will result in keeping obsolete/unclean design. Macro thinks we are ok with obsolete[3]/problematic[4] design, i.e. current OO API, because it works/enough for him. IMHO, this isn't a reasonable reason for voting "no", but it's great to hear the reason. I can point it out "it does not seem reasonable reason for me" at least. Bob and Levi seems strongly insisting use of TypeError rather than error. It's irrelevant for this RFC.[5] IMHO. We don't even have guideline nor RFC for exception usage currently. Do you really think we should keep obsolete/unclean API for this reason? Other "no" voters do not state reason why. What's the reason for against this RFC? I'm not a perfectionist, so I don't mind much to keep obsolete, unclean and incomplete[6] design, but I do think people who vote against RFC must expose the reason. It's technical discussion after all. Thank you for your feedback! Regards, [1] The reason why user defined serializer is not exposed is "register_globals compliance required special serialization format". [2] Requires needless serializations, save handler calls. It's dirty hack rather than API. [3] OO API was added to address "user defined serializer is not exposed" issue. Internal save handler as base object is obsolete design now. [4] We have/had number of crash bugs for hacky OO API design. [5] Session module uses errors now. Exception adoption should be done at once for a module. This requires other RFC. [6] Procedural API cannot encrypt/validate/serialize session data. P.S. I should have realize sooner that the new function name should be session_set_serialize_handler() rather than session_set_serilizer(). session_set_serialize_handler() is consistent with INI setting name and save handler feature. Does this change require vote restart? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
