Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86886
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Andreas Heigl'" <andreas@heigl.org>,
	<internals@lists.php.net>
Cc: =?utf-8?Q?'C=C3=B4me_BERNIGAUD'?= <come.bernigaud@opensides.be>,
	"'Kalle Sommer Nielsen'" <kalle@php.net>,
	"'Ferenc Kovacs'" <tyra3l@gmail.com>
References: <558ACF4D.6030506@heigl.org> <07fd01d0af5f$8f648d70$ae2da850$@belski.net> <558C4F20.6000103@heigl.org>
In-Reply-To: <558C4F20.6000103@heigl.org>
Date: Thu, 25 Jun 2015 23:00:23 +0200
Message-ID: <090f01d0af89$f5fe2bc0$e1fa8340$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKMcA8nxQNvo5Y2GC1s9RHT4hMt3AGX7KCtAh6hYX2cKHaUsA==
Content-Language: en-us
Subject: RE: [PHP-DEV] Deprecating ldap_sort
From: anatol.php@belski.net ("Anatol Belski")

Hi guys,

Kalle and me have now agreed, that the deprecation is feasible. In a =
normal case it would require an RFC, but this particular case wouldn't =
profit from it anyway. If the dependency library doesn't provide the =
symbols required, there's nothing to discuss or decide.

> -----Original Message-----
> From: Andreas Heigl [mailto:andreas@heigl.org]
> Sent: Thursday, June 25, 2015 8:58 PM
> To: Anatol Belski; internals@lists.php.net
> Cc: 'C=C3=B4me BERNIGAUD'; 'Kalle Sommer Nielsen'; 'Ferenc Kovacs'
> Subject: Re: [PHP-DEV] Deprecating ldap_sort
>=20
> Hi Anatol.
>=20
> C=C3=B4me already replied to the technical aspects of what we are =
trying to do.
>=20
> Am 25.06.15 um 17:56 schrieb Anatol Belski:
> > Hi Andreas,
> >
> >> -----Original Message-----
> >> From: Andreas Heigl [mailto:andreas@heigl.org]
> >> Sent: Wednesday, June 24, 2015 5:40 PM
> >> To: internals@lists.php.net
> >> Cc: C=C3=B4me BERNIGAUD
> >> Subject: [PHP-DEV] Deprecating ldap_sort
> >>
> >> Hi everyone.
> >>
> >> C=C3=B4me Bernigaud and myself are currently cleaning up the =
LDAP-Extension
> >> (Well, C=C3=B4me is doing the hard work and I'm trying to assist in =
some
> >> way). We would like to bring it in line with a more recent version =
of
> >> the OpenLDAP-lib. Currently the plan is to require OpenLDAP 2.4 as =
the
> >> minimum version to build ext/ldap against. This is on a very good =
way [1].
> >>
> >> But in said OpenLDAP-library the ldap_sort-function already has =
been
> >> marked as deprecated [2]. Therefore we'd like to at least mark PHPs
> >> ldap_sort function as deprecated also.
> >>
> >> The current rewrite will make it possible to later use the =
server-sided
> >> sort functionality so there will be only limited need for the =
current
> >> (client sided) ldap_sort function.
> >>
> >> As it's a BC-break to remove the ldap_sort function will we have to
> >> setup an RFC for that? Or is it a plain "mark it deprecated in PHP7 =
and
> >> throw it away in PHP8" kind of decission? And will it be possible =
to get
> >> that marked deprecated in 7 at all?
> >>
> > I've a few questions to this. Can it be implemented with non =
deprecated
> symbols? Or maybe, can the server side sort not be done with the same
> function, as it's probably the same job? Or it will be really not =
required? Any info
> about the plans on the openldap side to remove the deprecated symbols =
(AFAIR
> those are kept already for years)?
> >
> > We're currently don't know, how wide this function is used and how =
much it
> would break. In general, deprecating it if there's a strong reason, =
could be
> sufficient. If there's a small possibility to keep this function, we =
should use it. Fe
> maybe it could kept and enabled with a configure option, that way =
it'll be still
> usable.
>=20
> I might have not expressed myself correctly about the deprecated =
thingy.
> I was actually refering to whether it would be possible to raise an
> E_DEPRECATED for calling ldap_sort. If we could bring that into PHP7.0
> we would be able to remove it from PHP7.1 and get a clean codebase
> without any functions marked as deprecated in the underlying lib.
>
Yes, I've understood what you do. I was working/reviewing some ext/ldap =
patches previously, and also I'm building the windows dependencies for =
ext/ldap. And I think your work is very much appreciated - it brings PHP =
in a good position with the future, also with the todays distributions =
which already compile openldap without deprecated symbols.

> If we'd have to wait for PHP7.1 for the E_DEPRECATED that would mean =
we
> can remove the deprecated function_calls at the earliest in PHP7.2.
> That's a long timescale ;)
>=20
> >
> > Any feedback from the ldap users were appreciated here, as well.
>=20
> I don't use it ;)
>=20
> I've checked phpLdapAdmin (not used), GOsa (not used) and Zend\Ldap
> (sadly used, but I can rewrite that part) but that are just three libs
> out there out of so many self-written scripts....
>=20
Yeah, deprecating will give enough time to update these parts. =
Especially if you jump in and do a PR.

Regards

Anatol