Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions

Hi all, I did this prototype/concept about SessionHandler, SessionHandlerInterface in PHP 5.6: https://gist.github.com/narfbg/9643416 In the context of this discussion, the important part is the updateTimestamp() method (in relation to 'lazy_write'), you should ignore the rest (for now). I want to discuss it here first before updating the RFC with it. So, I had a chat with Yasuo about it to identify the problems and/or limitations and this is the most important one: The patch (https://github.com/php/php-src/pull/628) doesn't allow calling parent::updateTimestamp() and users should call parent::write() instead. This is because there are PECL extensions that provide a session handler and they won't have support for that, which is hard to detect at runtime. However, I don't think that this is convenient, nor that documenting this is better than documenting that PECL extensions might not support the parent::updateTimestamp() call. To me, that's an unnecessary limitation and here are the alternatives: 1. Don't declare SessionHandler::updateTimestamp() if session.save_handler doesn't support it and put a big red warning in the docs that PECL extensions might lack the method. I think this is a good trade-off, given that most users trust (or have) only "stock" PHP extensions and can benefit from this. Also, this wouldn't be a precedent - you can take mysqli and it's dependancies on mysqlnd for example (where the docs mention this very briefly). 2. Scrap the updateWhatever() method and just modify write() to only update the timestamp when necessary. I have no idea why nobody has thought about this previously. The 'lazy_write' idea is inspired by a feature request from 2002 (https://bugs.php.net/bug.php?id=17860) that simply asks for an API identifying whether $_SESSION has been changed or not, or in other words - and API saying whether session data or only the timestamp should be updated. Now, Yasuo prefers providing explicit API for the lazy_write feature (namely, the updateTimestamp() method), but simply providing such a flag via i.e. yet another magic constant, similar to SID, solves ALL of the problems: - No API changes - No BC breaks - No effect on PECL extensions that don't support it IMO, that's way more flexible and would allow doing lazy_write by default, no option - after all, the feature represents a performance improvement. It also solves another, side-effect problem: the SessionUpdateTimestampInterface, that currently exists only because of internal implementation details. Thoughts? More suggestions? Concerns? Cheers, Andrey.