Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73385
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>
Cc: <internals@lists.php.net>
References: <CAPhkiZyFHshFc56UEHiDFK9k801ztno+xoS82Yf6qAcwiRPg1A@mail.gmail.com>
In-Reply-To: <CAPhkiZyFHshFc56UEHiDFK9k801ztno+xoS82Yf6qAcwiRPg1A@mail.gmail.com>
Date: Mon, 24 Mar 2014 10:39:33 -0700
Message-ID: <010e01cf4788$05f3c5a0$11db50e0$@devtemple.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIdnyEwmpNQ9DHEQ0tK0vXPLszKb5pTvgdg
Content-Language: en-us
Subject: RE: [PHP-DEV] [RFC] session_start(), read_only, lazy_write; Take 2
From: bill@devtemple.com ("Bill Salak")

>After feedback on the original proposal, I've updated the RFC about =
changing lazy_write, read_only and I'm re-posting it. The first =
discussion thread got somewhat spammy, so I thought a new one should be =
better.
>
>https://wiki.php.net/rfc/session-read_only-lazy_write
>
>Waiting for your comments on here. :)
>
>Regards,
>Andrey Andreev.

Hi Andrey,
In your proposed example problematic use case your code shows that the =
following happens:

 - Request 1, opens session, populates _SESSION superglobal, closes =
session (no writeback)
 - Request 2, opens sessions, unsets $_SESSION['logged_in'], writes =
session
 - Request 1, checks value of $_SESSION['logged_in'] and does not =
recognize that the value of $_SESSION['logged_in'] has changed by =
Request 2

The net result for Request 1 is exactly the same as what we have today =
except that today the path to this same result is that Request 2 can't =
read or modify the data until Request 1 finishes. Because this is not a =
new or unexpected result I don't see how this is "downright dangerous" =
unless the user misunderstood what the new functionality does and =
designed solutions around this misunderstanding that exposed problems in =
their new code. I think this is actually the core of your RFP on this =
point which I think just boils down to - is read_only the best name for =
this flag ? I personally think it's a descriptive and self-evident name =
for the option because the session in Request 1 *is* read only (can't be =
written to) and that what you think of as a read only is actually better =
called a "read lock". Ultimately I don't care what it's called so if =
that's all this is about then I have no more interest in this part of =
the discussion and am happy to let those who care determine the name of =
the option.

On your point about some future implementation of a write blocking, =
read-shared, session lock - it's an interesting idea.

On your point about, "Maybe, if session_start() didn't accept mode =
parameters, that would've been fine. However, session_start() also =
accepts all session.* INIs + 'lazy_write' and all of those are modes of =
operation and not additional actions per se. So that makes it not only =
strange, but also inconsistent", you've lost me -I don't see a problem. =
If I call session_start and I can pass in a bunch of options about how =
the session will act in this call stack that seems like the best and =
most pragmatic solution. The distinction between modes of operation and =
additional actions seem like a semantic nitpick that end-users wouldn't =
intuitively understand. In other words, it seems counter-intuitive to =
work some other way and wouldn't produce more easily read/written code =
to have it different.

Best,
Bill Salak