Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZx_ztbVXFm10_4MSQyqkBDYVqBiCmNBdF4k7N9fev5uLQ@mail.gmail.com>
References: <CAPhkiZx=0Vr5p=7VZJD4PeD0ub-khSVMw3G03QhO8CC4xxm11A@mail.gmail.com>
 <CAGa2bXZTU5HzM4oXyiu0PnS=W2Oz1uLP_BnyWBUXyYUTO0tMYg@mail.gmail.com>
 <CAPhkiZz_d_wFPgwwYXJD-A+tz0Uf9KQ6uXNi1HhZGWFF1=W91A@mail.gmail.com>
 <CAGa2bXY86ri7b=rquo8Vbbh5ZoHOkwGBRoPWPup-SVPMu0WEgg@mail.gmail.com>
 <CAPhkiZyEqcx+UTPzpyYjz9pxWJnCNDO9pUMQNxvTpnrxmez9nw@mail.gmail.com>
 <CAGa2bXb5rLU26NDDHkWDw-FYf=vh2J=LAGFrqU3A3JJpOTY_dA@mail.gmail.com>
 <CAPhkiZyyXuqqybs+q8rnp_eJZDU0De2wMqwfv5mWiihr9GsueQ@mail.gmail.com>
 <CAGa2bXboo3CGOP9x+fW0Q98aniBcXejkGSJv5=qygL9ia67FbA@mail.gmail.com>
 <CAPhkiZzaTCE6sR=Rt=4VBmVOCo+uSQMREpf-fg6hWBrbCW+RXQ@mail.gmail.com>
 <CAGa2bXYWVoX_05BdS0M-V5G+B=4v-W-DPbWT8-vPrtd=gJtcCg@mail.gmail.com>
 <CAJ26g5TfiwjECNH_GbU6OCwCJdCCRJxKLUBL6wtw89XNo8P2eg@mail.gmail.com>
 <CAGa2bXbeucsEK2X1_wvtY_zMXs6guQAWxEMFhpjhyyOopq3sog@mail.gmail.com>
 <CAEZPtU6J01hP2+xjRUhTY9+rq9dTZyPOv9Mes_Xt0jiogsCE9w@mail.gmail.com>
 <CAPhkiZx3iUo=4cJYkB7KPcD8TMs79kvLBrnBdGUZ4YqTq-+h-Q@mail.gmail.com> <CAPhkiZx_ztbVXFm10_4MSQyqkBDYVqBiCmNBdF4k7N9fev5uLQ@mail.gmail.com>
Date: Fri, 14 Mar 2014 05:09:01 +0900
Message-ID: <CAGa2bXafxzFTMRfn16JNDgWm2tPQeuYE8cdqg9BbRsKSy3S1QA@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Pierre Joye <pierre.php@gmail.com>, Patrick Schaaf <bof@bof.de>, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11349628a070c604f482888a
Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11349628a070c604f482888a
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Fri, Mar 14, 2014 at 1:56 AM, Andrey Andreev <narf@devilix.net> wrote:

> Another 2 items that didn't go through the RFC process or any discussion:
>

These are covered RFC discussions and/or some other discussions in this
list.


>  - Implemented Request #20421 (session_abort() and session_reset()
> function). (Yasuo)
>
> https://bugs.php.net/bug.php?id=20421
>
> Does this change mtime of the session?
> I also have other (rather philosophical) arguments against this, but I
> don't want to get deeper into it now ... it should just be reverted
> together with session_serializer_name(), session_gc() on the basis of
> no discussion at all.
>

abort and reset were discussed in RFC discussion.  It was't a long
discussion though. Since this is just a simple API addition, it added
simply.

What's your reason?


>
>  - Implemented Request #17860 (Session write short circuit). (Yasuo)
>
>    https://bugs.php.net/bug.php?id=17860
>
> The problem with that is that there's no API exposed for custom save
> handlers to decide when to only update mtime or the whole session. I
> think the question was exactly about that, actually.
> It is also not clear how is that implemented and for which of the
> available session handlers ... is it all of them?
>

This one is discussed in following RFC, since it affects existing behavior.
Some one pointed out and the RFC was created.

Then later (note that it *already is implemented*), it was voted as
> part of this RFC, which made it optional:
>
>     https://wiki.php.net/rfc/session-lock-ini
>
> This RFC is broken to begin with ... what ended up as accepted from
> this RFC was actually very far from the main intention behind it (and
> it silently accepted passing ini options to session_start() with no
> explicit voting for that - just saying, otherwise I like that
> feature).
> Also, there's no description for "read_only" except the obvious - that
> it only reads. It should at least mention that a shared lock can be
> used for that case.
>
> IMO, if this feature had gone through proper discussion instead of
> just presenting a yes/no option as part of another change, we'd end up
> with a different solution.
>
> Actually, I'd like to ask if it's possible for an RFC to override a
> decision taken from a previous one? And can it be done quick? Or if
> not - can that be postponed for 5.7?
> The lazy_write option is nice, but it's not optimal and it would be
> embarassing if it makes it into 5.6 only to be later reversed in favor
> of a better solution. What I'm thinking of is a session_is_changed()
> function and "lazy_write" at all times (there's no reason for that to
> be optional).
>

You should comment during discussion. There was long discussion for this.

Shared lock could be used easily for some session storage, but it requires
save handlers modification and it could be implemented _independent_ of
read_only. Web apps must return response ASAP. Therefore, any locks that
could be avoided should be able to be avoided including read(shared) lock.

Anyway, read_lock is confusing unless save handler API supports it. i.e.
User cannot know if it really support read_lock like current
use_strict_mode.

Why not write a RFC for read_lock? I'm OK to implement it if you would like.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11349628a070c604f482888a--