Hi Yasuo, On Thu, Nov 6, 2014 at 3:42 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > 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.
You think you know better what *my* motivation was? (don't answer) > 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. But it would still be a BC break. Also, the commit we're talking about was made way before I objected anything, don't throw that one on me. >> 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. You're still thinking in the context of your RFC and the patch that was never merged. The issue at hand is that write() is not called and the method that I described clearly solves that issue. Whether you think that's "the way to go" is another story. >> 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. I am very well aware of how HTTP works, thank you. Due to lack of context and for the sake of remaining on good terms, I'll refrain myself from replying in a more elaborate manner. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
