Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91033
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
To: internals@lists.php.net
References: <6F.D4.55829.C14FCA65@pb1.pair.com>
 <CAF+90c8ojjKqHqZcOZbanji3YokoQQHmZFjxKRWyz_znNMb-hQ@mail.gmail.com>
 <58.11.35275.ADC3DA65@pb1.pair.com>
 <CAGa2bXZ6G7UxwOc8hijU+Y2H1m61NSSmMmrQX7AJNG=Eog5PrA@mail.gmail.com>
Message-ID: <56ADD570.1000003@lsces.co.uk>
Date: Sun, 31 Jan 2016 09:35:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ6G7UxwOc8hijU+Y2H1m61NSSmMmrQX7AJNG=Eog5PrA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Should we rethink the 50%+1 requirement
 fornon-"language changes"?
From: lester@lsces.co.uk (Lester Caine)

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