Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103471 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 44850 invoked from network); 21 Nov 2018 12:59:44 -0000 Received: from unknown (HELO librelamp.com) (45.79.96.192) by pb1.pair.com with SMTP; 21 Nov 2018 12:59:44 -0000 To: internals@lists.php.net References: <47dd2988-6fb2-0685-efa1-a58cb55e9ecb@gmail.com> <563360e1-aa2f-6a2f-7299-caf9b85f2fff@gmx.de> <10374235-1d67-c300-2957-18bed9bd56c5@gmail.com> Message-ID: <4cbe34df-02e0-78c3-6123-aa641fbbe20d@librelamp.com> Date: Wed, 21 Nov 2018 01:21:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: patch for imap bug 77153 From: alice@librelamp.com (Alice Wonder) On 11/20/2018 11:38 PM, Kalle Sommer Nielsen wrote: > Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye : >> Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really >> not maintained well, both c-client and the ext. Would it be possible to >> consider it? > > I remember we have spoken about this in the past and it seems that > everytime it comes up, is the argument that we don't provide a real > mail alternative. I mean sure there is lots of userland based > implementations and all, but I still think that PHP should provide > something out of the box, but I do agree that at one point, the > security concerns will start to vastly outweight the unmaintained > library, but its really something that should be discussed for a > future release. > > > To me it is not logical to continue maintaining a wrapper to an abandoned library just so the functions continue to exist for the sake of existing. That seems like a bad policy. Import the library into core and maintain it or write an alternate from scratch - IF the functions it provides truly has market demand. Otherwise remove support. Those seem to me like the only logical options. Nostalgia is not logical. I just checked my roundcube install, it does not use this wrapper, so clearly IMAP connectivity can be obtained through other means. That makes me feel inclined to believe this wrapper is not needed. I don't vote, but PHP shouldn't be like OpenSSL was with things like heartbeat - an extension almost no one used and seemingly no one maintained yet it was everywhere and vulnerable. Maybe stick the IMAP wrapper in PECL if someone needs it badly enough to be willing to maintain the wrapper there. Less is more, more or less.