Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97333
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.149 as permitted sender)
Message-ID: <BLU437-SMTP10545B216F76C347BCDD6CDE2850@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
In-Reply-To: <CAGa2bXYttcQfWfiSXH0=_Lps1bQrfhTz=iVaVrUAQ6y7USigpg@mail.gmail.com>
Date: Wed, 7 Dec 2016 23:40:17 +0100
CC: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAGa2bXbsgQvAuLF_gdZShFP8RbJhtJ8njYi2q=Y977B8EDz=BA@mail.gmail.com>
 <CADyq6sJaN1fLUBGEwWvjLu9tt2Gm=je8qG8wAik01+7NU+cHXQ@mail.gmail.com>
 <CAGa2bXYaX05JbJAvyxfSJyy6xiA+4u14NPFGYwScL4aoOFQGhw@mail.gmail.com>
 <70.0A.11772.8B1E7485@pb1.pair.com>
 <CAGa2bXbbmPoByzGrFd=7qE0dCEJvmcTRZ5W0mKNTgZXKZDwBdw@mail.gmail.com>
 <CAGa2bXarCxSfn4cf2EbxG0sB+A_etOmcduNZ6r=7KZQdJimccg@mail.gmail.com>
 <CAGa2bXYttcQfWfiSXH0=_Lps1bQrfhTz=iVaVrUAQ6y7USigpg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer
From: bobwei9@hotmail.com (Bob Weinand)


> Am 07.12.2016 um 21:49 schrieb Yasuo Ohgaki <yohgaki@ohgaki.net>:
>=20
> Hi voters,
>=20
> Following people are vote against this RFC for now.
>=20
> bwoebi (bwoebi)
> danack (danack)
> hywan (hywan)
> leigh (leigh)
> levim (levim)
> nikic (nikic)
> ocramius (ocramius)
> peehaa (peehaa)
> ryat (ryat)
>=20
> I suppose bwoebi and levim vote against due to error and exception
> usage. Thank you for feedback, Levi and Bob.
>=20
> How many of you vote "no" because of error and exception issue?
>=20
> IMHO. Exception in session module is out of scope of RFC,  mixing
> error and exception in a module is confusing and inconsistent. Session
> module is not language engine, so I'm not 100% sure if we should use
> TypeError exception for normal module's invalid return type. However,
> I don't mind much to use exception if many of us insist.
> (BTW, "interface" parameter issue is out of scope this RFC also. It
> should be addressed by OO API cleanup RFC consistently. I'm trying to
> resolve issues one by one.)
>=20
> I wonder how many of you understand this RFC is really a
> "register_globals" legacy cleanup? Do you really think we should keep
> "register_globals" legacy because of irrelevant issue?
>=20
> Thank you for feedback!
> Unless there are feedbacks, nobody cannot figure out what's the reason
> behind for "no" votes.
>=20
> Regards,
>=20
> --
> Yasuo Ohgaki

Exceptions is one thing.

That's why I initially voted no.

Though thinking more about it, I still do not see the need.

session_set_save_handler() ultimately can just do the job completely.
Encryption? save_handler can do that.
Saving to somewhere else? It can do that.

Note that your RFC is not a replacement. Especially the last thing, =
saving to somewhere else, which isn't a file, cannot be prevented =
without it.

If there were:
save(string $uuid, array $data)
read(string $uuid): array $data

That'd make much more sense. Having to do flock() + file_get_contents() =
/ file_put_contents() yourself to sys_get_temp_dir()."/$uuid" is not a =
problem in case you want to save it yourself.
Perhaps we should provide session_default_write(string =
$data)/session_default_read(string $data). I do not care too much.

And how is that related to register_globals?!

If this RFC were a proper replacement with also a proposed deprecation =
plan (e.g. in 7.4 (or 8.0) whatever comes first), that'd be a plus too. =
But currently it looks like we're heading to just have yet another =
separate system for sessions.

Bob=