Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <5324FE40.1070704@sugarcrm.com>
Date: Sat, 15 Mar 2014 18:28:32 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, Andrey Andreev <narf@devilix.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAPhkiZw5xWRkc=ofh-nB5ZkjfThZFkH_+pK5RZaQFLKhno7u7A@mail.gmail.com> <CAGa2bXZiBuw_L_ehvTZb5_UUedtbS0n4GXYUjtKix0S9DX_8KQ@mail.gmail.com>
In-Reply-To: <CAGa2bXZiBuw_L_ehvTZb5_UUedtbS0n4GXYUjtKix0S9DX_8KQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about read_only,
 lazy_write sessions
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>> I'm announcing the following RFC for discussion, with the hope that it
>> can get through before the PHP 5.6 release:
>> https://wiki.php.net/rfc/session-read_only-lazy_write

Frankly, I'm not sure what is the point of this - submitting RFC that
says "let's throw out RFC that we just accepted". If somebody didn't
want that RFC to happen, he'd vote against it, no?

I also don't understand what's the problem with read only option. Read
only option means only one thing - you're going to read the session, but
not write into it. Hence read only. Your scenario with login check is
not a problem because all session data are always read at the beginning
of the session. If another session changes the state later, it in any
case can not influence the session that have already read the data. The
only change is that now the session can say "I am not going to change
the state, nothing I am doing should change the state, so I'm not going
to waste my time on writing anything back".
Not allowing $_SESSION to be written sounds pretty useless to me, since
it is not going to be written anywhere anyhow, but this option does not
prevent implementing it in any way.

As for lazy_write, incomplete is not the reason to revert accepted
feature. Anything can be improved and amended, if we rejected features
because they could be improved, we'd never add anything. There is a use
case for this feature to exist, as an extension of the read only option
- it is a case where the session *might* change the state, but not
always does. So you have three options now:

1. My request is never going to change the state => use read_only
2. My request might change the state and thus I need exclusive lock =>
use lazy_write
3. My request always changes the state => use defaults

The difference between 1 and 2 is shorter period under lock, between 2
and 3 - saving time on transmitting data over the wire that are already
in session storage anyway. As for UPDATE_FUNC, I understand this is only
for updating "last used" if it exists and may be defaulted to nothing.

Again, nothing prevents us in PHP 6 from changing the defaults and
making this option part of the default option set.

>> As noted in it, I don't feel like
>> https://wiki.php.net/rfc/session-lock-ini was handled properly. Lack
>> of attention to it alone is demonstrated by the fact that a total of
>> only 10 people have voted. I hope that this follow-up receives more
>> attention, so that we can avoid a potential mess.
>>
> 
> "lazy_write" is not accepted. So you don't need to mention it in the RFC.
> 

The vote result says "yes" on "Read only, lazy write option".

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227