Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86899 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 15546 invoked from network); 26 Jun 2015 09:25:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jun 2015 09:25:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=jan@horde.org; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=jan@horde.org; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain horde.org does not designate 82.98.68.218 as permitted sender) X-PHP-List-Original-Sender: jan@horde.org X-Host-Fingerprint: 82.98.68.218 fra.ammma.de Linux 2.6 Received: from [82.98.68.218] ([82.98.68.218:56918] helo=fra.ammma.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/E4-57329-08A1D855 for ; Fri, 26 Jun 2015 05:25:22 -0400 Received: from ammma.de (fra2-hb [192.168.1.12]) by fra.ammma.de (Postfix) with ESMTPS id D37DE5B050D for ; Fri, 26 Jun 2015 11:25:17 +0200 (CEST) Received: from mail.ammma.net (ns.ammma.mil [192.168.110.1]) by ammma.de (8.11.6/8.11.6/AMMMa AG) with ESMTP id t5Q9PGF16757 for ; Fri, 26 Jun 2015 11:25:17 +0200 Received: from neo.wg.de (hydra.ammma.mil [192.168.110.1]) by mail.ammma.net (Postfix) with ESMTP id 3F71841384 for ; Fri, 26 Jun 2015 11:25:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by neo.wg.de (Postfix) with ESMTP id 0C49C191A130 for ; Fri, 26 Jun 2015 11:25:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at wg.de Received: from neo.wg.de ([127.0.0.1]) by localhost (neo.wg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gInyYuoGo7kU for ; Fri, 26 Jun 2015 11:25:05 +0200 (CEST) Received: from neo (localhost [IPv6:::1]) by neo.wg.de (Postfix) with ESMTPS id 5E8C0191A12D for ; Fri, 26 Jun 2015 11:25:05 +0200 (CEST) Received: from 192.168.60.175 ([192.168.60.175]) by neo.wg.de (Horde Framework) with HTTP; Fri, 26 Jun 2015 11:25:05 +0200 Date: Fri, 26 Jun 2015 11:25:05 +0200 Message-ID: <20150626112505.Horde.107_6ptptF6-qasiwr5pz7t@neo.wg.de> To: internals@lists.php.net References: <558ACF4D.6030506@heigl.org> <07fd01d0af5f$8f648d70$ae2da850$@belski.net> <558C4F20.6000103@heigl.org> In-Reply-To: <558C4F20.6000103@heigl.org> User-Agent: Internet Messaging Program (IMP) H6 (7.0.0-git) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Deprecating ldap_sort From: jan@horde.org (Jan Schneider) Zitat von Andreas Heigl : > Hi Anatol. > > Côme already replied to the technical aspects of what we are trying to do. > > 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ôme BERNIGAUD >>> Subject: [PHP-DEV] Deprecating ldap_sort >>> >>> Hi everyone. >>> >>> Côme Bernigaud and myself are currently cleaning up the LDAP-Extension >>> (Well, Côme 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. > > 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. > > 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 ;) > >> >> Any feedback from the ldap users were appreciated here, as well. > > I don't use it ;) > > 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.... FWIW Net_LDAP and its successors Net_LDAP2 and Horde_Ldap don't use ldap_sort anymore since 2006 either. -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject