Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYaX05JbJAvyxfSJyy6xiA+4u14NPFGYwScL4aoOFQGhw@mail.gmail.com>
References: <CAGa2bXbsgQvAuLF_gdZShFP8RbJhtJ8njYi2q=Y977B8EDz=BA@mail.gmail.com>
 <CADyq6sJaN1fLUBGEwWvjLu9tt2Gm=je8qG8wAik01+7NU+cHXQ@mail.gmail.com> <CAGa2bXYaX05JbJAvyxfSJyy6xiA+4u14NPFGYwScL4aoOFQGhw@mail.gmail.com>
Date: Mon, 5 Dec 2016 14:52:10 +0100
Message-ID: <CADyq6s+hHCA4K5a4HJfR9yX4E5mbA+_CM5wLA7xn8ONt4aNpuw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0103e04e54aacb0542e9996c
Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer
From: ocramius@gmail.com (Marco Pivetta)

--089e0103e04e54aacb0542e9996c
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 5, 2016 at 4:31 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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.
>

Yes


> 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.
>

Number of bugs? In which adapters? There are well tested session
savehandlers out there, and I'd trade a userland bug for an internals bug
anytime.


> Secondly, the only use case, that current OO save handler design is
> useful, is read()/write() override to encrypt/validate session data.
>

What does this RFC do that a custom session savehandler *CANNOT*?


> Thirdly, I fixed _many_ of current OO API bugs, but fixing them all is
> impossible by design.
>

It would need a deprecation of the current session module, and a
replacement with a newer, cleaner API.


> 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?
>

There is a problem with adding a half-feature to fix half the problem, and
then having to deprecate this half-feature when the new full solution is
actually replacing it in a correct way.



> > 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.
>

It is confusing that we now have two ways of passing down serializers for
sessions.
The Redis session savehandlers already use igbinary where applicable, for
example, so why do I need to have a second equivalent API? Providing a
userland base session savehandler with pluggable serializers (written in
PHP, not in C, please!) is a much better idea.

The RFC allows to save session data in whatever format. e.g.
> XML/JSON/BSON/etc. This is _impossible_ by save handler submodule


Savehandlers even save to flat DB tables, so I'm not understanding what is
being explained here...

Even in the docs, the first example shows how to add encryption to a custom
savehandler: https://secure.php.net/manual/en/class.sessionhandler.php

Adding a custom serialization is as simple as an `unserialize()` + custom
serializer call (Yes, I can already hear all those microseconds screaming!
The horror!)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--089e0103e04e54aacb0542e9996c--