Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73364
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain devtemple.com from 50.116.27.81 cause and error)
To: "'Andrey Andreev'" <narf@devilix.net>,
	"'Yasuo Ohgaki'" <yohgaki@ohgaki.net>
Cc: "'internals'" <internals@lists.php.net>
Date: Sun, 23 Mar 2014 00:28:01 -0700
Message-ID: <002f01cf4669$6e3b1570$4ab14050$@devtemple.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ac9GYukWd6NT4S47Q1SNBaOLlO3cIw==
Content-Language: en-us
Subject: session_start read_only
From: bill@devtemple.com ("Bill Salak")

>>> It is not broken functionally, indeed.
>>> It's broken by design - if I write session_start(), options or not, =
I=20
>>> would never expect it to immediately close the session. It's highly=20
>>> misleading and this will lead to a lot of abuse.
>>
>>
>> I don't want to confuse users.
>> Better name would be appreciated.
>>
>> Perhaps, "close" may be better option name.
>>
>> session_start(['read_only'=3D>true]);
>>  =E2=86=93
>> session_start(['close']=3D>true);
>>
>> Any comments/better names?=20
>
>I'd rather suggest this to be a separate function and not an option for =
session_start(). I've got this coverered in a draft RFC that I will =
announce for discussion later today.

Hi Andrey,=20
referring to your comments above and the related content at =
https://wiki.php.net/rfc/session-read_only-lazy_write, your example =
problem use-case/result -=20

// $_SESSION['logged_in'] has been set in a previous request
Request 1: session_start(['read_only' =3D> TRUE]);
Request 2: session_start(); unset($_SESSION['logged_in']); =
session_write_close();
Request 1: if ($_SESSION['logged_in']) { /* logic */ } // evaluates to =
TRUE

works the same way today that you describe as a problem, if I'm not =
mistaken.=20

 - Request 1 locks the session and Request 2 waits.=20
 - Request 1 finishes and unlocks the session.
 - Request 2 can now get on with its work.

I initially suggested this "read_only" feature to Yasuo (as he has =
implemented it today) in order to solve this blocking wait time problem. =
The use case I wanted a solution=20
for is common in the applications I design/work-on/see today which is =
modular AJAXy/independent access to PHP sessions, i.e. "is this user =
logged in and allowed to call this thing?"
In these use cases I often know I just need to read the session data and =
will not write to it therefore I just want the lightest, quickest =
read-and-release-session process possible for=20
near-concurrent access to reading the session. Actually writing+reading =
to a session (or any datastore for that matter) becomes a synchronicity =
issue which is fundamentally at odds=20
with a codebase designed around asynchronous access to state and needs =
to be solved for by the application architecture/design in those =
situations that need to have that sort of=20
protection. In other words, I believe the example problem use case =
you've posed is an application design problem not a language level issue =
IMO.=20

On a related note, your suggestion of a "true read only" implementation =
would presumably either throw an error on attempt to write to a session =
that was locked as "read only" or=20
would act as sessions act today, which is to say, wait for the session =
to unlock before writing to it. My gut reaction is that neither of these =
are better than what we have today but=20
the conversation is young and I'm interested to hear more.

One last point, the ability to "configure" a session through an array of =
options is very useful from an end-user code design point-of-view. =
Moving the ability to start a session as read
only to a separate function call than I would use to start a session =
otherwise forces choices in code design that can otherwise be much more =
elegantly handled through the use=20
of a single function with a configuration parameter.

Best,
Bill Salak