On 31/01/16 02:42, Yasuo Ohgaki wrote: > It's ok to reject a RFC by "I don't think it is not needed" for simple > additions like array_find_recursive() - it's imaginably RFC. However, > it is not ok for some change/addition like mine > https://wiki.php.net/rfc/precise_session_management > This RFC includes mandatory session management behaviors and not > disclosing why someone objects it, is not nice thing to see. Opposing > votes for "Precise Session Management" would mean most likely, "My > description was not good enough to be understood by everyone" or "Some > implementation is not preferred" or even "There are better ways to do > this". Turning that around ... Are there better ways of doing this? In situations where security is not an issue, such as private networks, many of the elements of 'making PHP more secure' simple add work without any real gain, but the fact that some interactions with the browser are now well out of date should prompt a discussion to fix the whole process? We have improved international working, including handling timezones, but there is still no mechanism to establish an anonymous users local timezone. It's only a small hole, but twice a year in a substantial part of the world the local time has holes and while running the server UTC allows the sessions to be consistent, the actual client time may be an hour adrift.
> 2/3 majority sounds good, if people who against a proposal explicitly > disclose the reason why. Reasons for opposition are required for > RFC/implementation improvements if it is needed. As Zeev has already demonstrated, the bulk of RFC's do not even really need a vote, and the minority objections perhaps simply need better understanding as you say. The problem that will remain is pushing stronger typing and naming of everything through the whole infrastructure? When some of us don't have a need for it while others think that it should be a default security issue? There is now a two stream model created because there was essentially no consensus on the issue and while some have 'backed down', it does not mean that moving further down that road is already a dun deal? I would prefer that my IDE dealt with many of the problems that others think should be 'compiled in' but both roadmaps are equally valid? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php