On Fri, Jan 31, 2014 at 4:47 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Daniel,
>
> On Fri, Jan 31, 2014 at 2:17 AM, Daniel Lowrey <rdlowrey@gmail.com> wrote:
>
>> On Thu, Jan 30, 2014 at 12:11 PM, Rouven Weßling <me@rouvenwessling.de
>> >wrote:
>>
>> >
>> > On 30.01.2014, at 04:15, Daniel Lowrey <rdlowrey@gmail.com> wrote:
>> >
>> > As I mentioned in the updated RFC
>> > text I think it makes sense to deprecate the specific wrappers in 5.6
>> and
>> > look to remove them in 5.7 as they're really unnecessary in light of the
>> > ability to specify flags for the specific individual protocols you wish
>> to
>> > use on a given stream.
>> >
>> >
>> > Please don't. By deprecating in 5.6 and removing in 5.7 (which would be
>> > faster than anything before) you'd royally screw everyone skipping a
>> > version - something that gets increasingly likely with the faster
>> release
>> > cycle.
>> >
>> > I'd suggest deprecating them now with this RFC and remove it in PHP 6,
>> if
>> > PHP6 doesn't come around they could still be removed in a future RFC.
>> >
>> > Best regards
>> > Rouven
>> >
>>
>> Sounds good to me. Will update the RFC for deprecation of the sslv2:// and
>> sslv3:// stream wrappers in 5.6 with removal planned for PHP 6.
>>
>
> I agree that obsolete protocol should be deprecated.
> However, removal is totally different. I would like to have *long* period
> before
> removing any feature from PHP whenever it is possible. It could be used as
> toy
> for security experiments as well as for incredibly old internal servers
> never updated.
> Perhaps, remove them for PHP 7 or even 8?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
I'm perfectly fine with a long period for removal. However I don't see any
reason to persist deprecated features into a PHP 6 version because all the
existing functionality is retained. I'm only deprecating the potentially
confusing protocol-specific stream wrappers -- not the ability to use the
old protocols. Even when the deprecated wrappers are removed the old
protocols will still be available.
I understand that it's a bit difficult to see the difference in the current
RFC version because I haven't added code examples yet. However, I finished
the implementation patch with tests today and will update the RFC either
this evening or tomorrow with a fully mature proposal. I've taken into
account everything that has been discussed to this point and am pleased
with the resulting solution (I think everyone else will be as well). I'll
mail the list when the "final" (subject to input) RFC is live on the wiki
and we can revisit the conversation if necessary.
As always, the input is greatly appreciated!