>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