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

Hi, >> I think defaults should not change in minor version, unless there's a >> very good reason for it, and here it's not a very good reason. Session I don't think 5.6 is looked at as a minor version. Features have been added, changed, deprecated and removed in previous 5.x releases. >> module is very sensitive, and doing changes in it should be very >> conservative to not break people's workflows. While new behavior serves >> an important use case, it may not be everybody's use case, especially >> with all handlers. Thus, I would rather have it an option - exactly as >> voted. When we move into PHP 6, where certain major changes are >> expected, we can change the defaults. But I think introducing such >> change in a minor version is unnecessary risk. >> And also it subverts RFC process as it's not what the vote was for, and >> it's a substantial change - default behavior change (means, everybody >> affected) instead of option (means, only people using the option affected Exacly why I wrote an RFC, except Yasuo already explained that current workflows (speaking of userland handlers) are not affected and BC is maintaned. > No problem. > > How about making it a INI option? It makes session_start() option handling > code > a little simpler. It's not mandatory, though. +1 from me, if it is to be kept as an option. > I found issue with object based user save handler. Unlike procedural user > save handlers, > object based user save handler uses previously used save handler as it's > base class (some what) Isn't that the whole point of it, that you can overload only specific parts of the default one? > I think we are better to have another SessionHandler object that support new > APIs. > We can handle create_sid() method rename with new object also. We may keep > current implementation undocumented and may document it new one > (createSid()) only. > I will name it "SessionUpdateTimestampHandler". If anyone has suggestions, > I would appreciate it. I object, although it should've been called SessionFilesHandler in the first place, that way we could also have SessionMemcacheHandler, SessionWhateverHandler - way nicer than it currently is, but again - not the point of this discussion. Cheers, Andrey.