Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97335
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: <BLU436-SMTP529249445031BBF07307D9E2850@phx.gbl>
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>
 <BLU436-SMTP529249445031BBF07307D9E2850@phx.gbl>
Date: Thu, 8 Dec 2016 10:02:02 +0900
Message-ID: <CAGa2bXYcye8F1dtapRiyAYGTBpofcagutRf0gDjYECJmKJ-7ZQ@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Tony Marston <TonyMarston@hotmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Bob,

Thank you for feedback!

On Thu, Dec 8, 2016 at 7:44 AM, Bob Weinand <bobwei9@hotmail.com> wrote:
> 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.

It's been years ago, so I barely remember the current OO save handler
API implementation discussion. If anyone remember the discussion,
please correct me if I'm wrong.

IIRC, when current OO API was introduced, user defined serializer was
considered also. However, serializers had to consider register_globals
compliance that registers session variable as a global vars via
session_register(). Unlike $_SESSION/$HTTP_SESSION_VARS,
session_register()ed global vars are marked as session variable even
when they are undefined. Serializers (php and php_binary) saves these
undefined global session vars with PS_UNDEF_MAKER/PS_BIN_UNDEF
and restores them. i.e. Session variables are designed to work like
other GPC "register_global"ed vars at first.

Note: I recently noticed that there are remained codes for global
session var support, so I created PR to remove them.
https://github.com/php/php-src/pull/2233

Because of PS_UNDEF_MARKER(undefined global session vars), it was too
easy for users to implement broken serializers at that time. Instead
of exposing serializer submodule to users, OO API was made to override
session read()/write() for encryption/etc. (I completely forgot about
this, but I remembered this when I discussed about this with Stas
about a year(?) ago) There were discussion about overriding
open()/close(). Broken open()/close() override would cause problems,
but overriding was allowed for consistency sake, open()/close()
override is allowed because it might be useful for some cases.

IMO, this design was reasonable choice at that time. Thankfully, we
removed register_globals support altogether. The choice became
obsolete. i.e. We can use normal serialization like "php_serialize"
serializer as well as JSON/XML/etc serialization.

We can comply original session module design now, serializer submodule
to convert/restore session data for saving/from retrieved data, save
handlers submodule to save/retrieve session data from db.

We may keep current OO API as long as users are using it, but I'll
propose new/clean/complete OO API before 7.2. i.e. No base object and
full method interface by a single interface definition - there are 3
interfaces now.

BTW, the main RFC objective is to allow "User defined serializer" as
RFC title states. Session data "encryption/validation/modification" is
subproduct.

Please note that users cannot write clean/efficient user defined
serializer without this RFC.

I hope I explained the background well.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net