Hi Adam, thanks for the explanations.
On Tue, February 3, 2015 08:10, Adam Harvey wrote: > On 3 February 2015 at 03:11, Anatol Belski <anatol....@belski.net> wrote: > >> properly after the voting phase the >> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the >> voting. Each item is voted separately. The voting ends on 2015-02-09 at >> 21:00 CET. >> > > To explain my -1s: > > > - ext/imap and ext/mcrypt: while I realise that the underlying > libraries are dead, these extensions are too widely used to straight up > remove them, I fear — we don't have obvious alternatives with simple > enough APIs that we can push users towards. I'd strongly support and > encourage a reimplementation of these extensions (in C or PHP) around > something supported if someone was able to step up and do the work, > otherwise yes, I'll pitch in to do the minimal work to port these to 7.0 > if required. For ext/imap I can point to this old thread: http://grokbase.com/t/php/php-internals/141zh29xs2/ext-imap-bye-bye-in-php-5-6 And at list this one living native PHP implementation https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and more library links in the older thread link above). With ext/mcrypt there are also libs, I can point at least to this one https://github.com/phpseclib/phpseclib which was available even before PHP5.3 i think. Interestingly it can rely on ext/mcrypt if available, otherwise it uses native PHP implementations. Though note that those both are already ported, they landed in the RFC exactly because of the dead dependency libraries. I can just enclose myself to the reimlementation/surrogate layer idea. Actually that would make sense also for the ext/regex which was voted to be removed in another RFC. Otherwise, i'd rather advise users to use the native PHP implementations. > - ext/pdo_dblib: ODBC is almost always the better way of interfacing > with SQL Server, but I don't think keeping this one around is doing anyone > much harm (as opposed to ext/mssql, which we should kill with fire for the > same reasons as ext/mysql). There's also the sqlsrv extension http://www.microsoft.com/en-us/download/details.aspx?id=20098 . I had no chance to check ext/pdo_dblib but it's stated as not ported yet on the PHPNG wiki page. > Abstentions: > > > - sapi/apache2filter: I wonder if someone would step up for that one > if we advertised more widely, given I believe that it is in actual use. > Unlike most of the other SAPIs, which are obviously dead, I'd > like to give this one a bit more time before the 7.0 feature freeze. > No movement on this so far in the PHP7 direction. Nobody is porting it, nobody is asking for that. > - sapi/milter: I'm at least passingly familiar with almost all of the > Web servers in the list, but I know nothing about the environments > this SAPI is used in. Can someone who is familiar with it describe the pros > and cons to dropping it? > It's a very exotic thing. As mentioned in the RFC, with this you can hook into the MTA process. But the PHP script is invoked fromwithin the MTA. > - ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this > functionality adequately? I feel that I know enough to vote on SQL Server > related topics, but haven't looked at actual Sybase for years. > Basically the same as apache2filter - no movement on this towards PHP7. Nobody is porting it, nobody is asking for that. If there are no constant maintainers for this, IMHO porting it once which is doable, won't bring anything good but tons of subtle bugs. Porting it once without real maintanance and usage, just because we want to have "sybase" in, i mean. I'm really curious about the stats after this RFC, which extensions/sapis turned out to have found a new home and maintanance somewhere like PECL :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
