Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97426
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbsgQvAuLF_gdZShFP8RbJhtJ8njYi2q=Y977B8EDz=BA@mail.gmail.com>
References: <CAGa2bXbsgQvAuLF_gdZShFP8RbJhtJ8njYi2q=Y977B8EDz=BA@mail.gmail.com>
Date: Fri, 16 Dec 2016 06:32:03 +0900
Message-ID: <CAGa2bXa=K4S=Q1rFxSeOGi69yQ2ay_p6W4Usmv+WYw3RqMmCZQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [RFC][VOTE] User defined session serializer
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi all,

On Mon, Dec 5, 2016 at 10:44 AM, Yasuo Ohgaki <yohgaki@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
yohgaki@ohgaki.net