Hi Andrey, On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev <n...@devilix.net> wrote:
> Short-term fix for 5.6 is obviously to revert the commit. I was vocal > mostly because of principle at the time, but this issue is an example > why. > Did you? I don't think so. The reason that I didn't provide that user land "update" API is your objection. If it is included, user had control even in this case. A long-term "fix" for 5.6 would be what I've done in userland recently > - continue to call SessionHandler::write() at all times, but _inside > of it_ call touch() instead of fwrite() if there's no new data. That > way custom session handlers wouldn't be affected, but the default one > would still provide a performance boost. This is of course if we do > want to keep the feature (I do), but considering that it was voted in > a slightly different form ... I'm just being egoistic with this > suggestion. > No. Providing userland update API just like C module save handler is the way to go as I implemented at first. Besides, the method that you described will not solve the issue reported by the bug. There is no point that provides different API for C and PHP written save handlers, IMO. For PHP7 though, I definately want a redesign of the session APIs and > it's on my TODO list for when I have some spare time to work on it. > I think you have misunderstanding for session management. One example is that you don't understand nature of browser and server communication. It's _asynchronous_ by it's nature, yet you insisted _syncronous_ operation. Without this understanding, session cannot be managed correctly/precisely. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
