session_start read_only

>>> It is not broken functionally, indeed. >>> It's broken by design - if I write session_start(), options or not, I >>> would never expect it to immediately close the session. It's highly >>> 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'=>true]); >> ↓ >> session_start(['close']=>true); >> >> Any comments/better names? > >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, 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 - // $_SESSION['logged_in'] has been set in a previous request Request 1: session_start(['read_only' => 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. - Request 1 locks the session and Request 2 waits. - 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 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 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 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 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. 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 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 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 of a single function with a configuration parameter. Best, Bill Salak