Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.181 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, Andrey Andreev <narf@devilix.net>
References: <CAGa2bXZqCd4g5BwzRxWsVw351G_o1+AkhGq3cdyKhUW39rm4Tg@mail.gmail.com>
 <56F1A28F.90000@pascal-martin.fr>
 <CAPhkiZyn1hh_kdR5sMCxHSw+=kabiPerNT8Y3o8-h6u9d45wNA@mail.gmail.com>
 <CAGa2bXaWFqM3n4swF8bpVNXo6vzCipSpJXgjBq2_xd1ou6TgMw@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <56F30047.3090707@gmail.com>
Date: Wed, 23 Mar 2016 13:44:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaWFqM3n4swF8bpVNXo6vzCipSpJXgjBq2_xd1ou6TgMw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Precise session management
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Offending features may be disabled/changed by INI settings. I think it ok
> to say pretty much no BC issue.

I think this approach will lead us into problems. "It may be disabled by
INI setting" does not mean the problem does not exist (and btw not
everything that changes can be disabled AFAIR). Most BC breaks have
workarounds, but they still are BC breaks. Moreover, some of the changes
are default changes, which means basically users will have to undo what
this RFC does - if we think they'd have to do it, why change it in the
first place?

I also feel that sheer size of this RFC, the fact that it tried to fix
many unrelated issues, and amount of changes it brings leads to the
situation where people don't really discuss it properly but instead rely
on claims in the RFC that everything is fine, because it is very hard to
properly consider changes of this size with this many moving parts. At
least the discussion on the list was rather scarce as far as I can see.

> The difference that user/3rd party save handlers will see is an additional
> array in session data. The additional array should not cause any problems
> with session save handlers.

The change is not limited to additional data. This additional data is
active - it controls how sessions are supposed to behave. All these need
to be updated when something happens, all these need to be checked,
validated and user for various logic on various stages of session
lifetime. So saying "it's just some additional data, nothing of it" is
not true - it's not just data. Maybe everything is still OK with the
session handlers - but this needs to be thoroughly verified, it does not
come for free.
-- 
Stas Malyshev
smalyshev@gmail.com