Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Just a quick side one, there's no way to make compatible calls from mcrypt to openssl using "rijndael-192" and "rijndael-256" ciphers, a compatibility layer is almost impossible. Only AES-128/192/256 (which variants of "rijndael-128") are possible on both extensions. On Mon, Feb 9, 2015 at 6:47 PM, Pascal MARTIN, AFUP < mail...@pascal-martin.fr> wrote: > > Le 02/02/2015 20:11, Anatol Belski a écrit : > >> 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. >> > > Hi, > > After discussing this RFC with other people at AFUP (we weren't that many > to participate in this discussion -- which probably indicates not many of > us care about keeping those), it seems we would be: > > * +1 to remove all SAPIs listed in this RFC > * +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred > keeping those, but a new major version feels like the right time to drop > them, if the underlying libraries aren't maintained anymore. > * +1 to remove ext/mssql and ext/sybase_ct > * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one. > > Thanks > > -- > Pascal MARTIN, AFUP - French UG > http://php-internals.afup.org/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Le 02/02/2015 20:11, Anatol Belski a écrit : 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. Hi, After discussing this RFC with other people at AFUP (we weren't that many to participate in this discussion -- which probably indicates not many of us care about keeping those), it seems we would be: * +1 to remove all SAPIs listed in this RFC * +1 to remove ext/imap and ext/mcrypt -- some of us would have preferred keeping those, but a new major version feels like the right time to drop them, if the underlying libraries aren't maintained anymore. * +1 to remove ext/mssql and ext/sybase_ct * and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one. Thanks -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Jan, On Wed, February 4, 2015 11:13, Jan Schneider wrote: > > Zitat von Anatol Belski : > > >> Hi Stas, >> >> >> On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote: >> >>> Hi! >>> >>> >>> 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). >>> >>> This is part of Horde with 9 listed dependencies and 9 suggested >>> ones, and probably also sub-dependencies. It is much less convenient >>> than having imap right here when you run PHP. And looks like on top of >>> that it lists PHP 7 as not supported. >>> I'm sure there are other imap implementations, but I wouldn't be that >>> quick in throwing out one that a lot of people may use. -- Stas >>> Malyshev >>> smalys...@gmail.com >>> >> Horde is being developed by a some ISP, so it's mostlikely gonna >> support PHP7, even if not already. But this is actually what one can say >> regarding PHP7 compatibility with any scripts at the current stage. >> > > FWIW Horde is an open source project and not developed by any ISP. > Furthermore we're actively testing against PHP 7 and already detected > (and reported) a few bugs an regressions in master. > Not that this matters for this discussion, just for completeness. > Yeah, thanks for extending this. I don't follow this project closely, but have read the ISP part here http://dev.horde.org/imap_client/ . If the IMAP client is not being funded but them anymore, heh ... the project itself is for popular enough to take that. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Tony, On Wed, February 4, 2015 10:56, Tony Marston wrote: > "Pierre Joye" wrote in message > news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com... > >> >> On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev >> >> wrote: >> >>> Hi! >>> >>> Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. >>> >>> I'm not sure - what is the dangerous part? Are you referring to some >>> published CVEs or other reports? Then it would be useful to list them >>> here and on the RFC. >> >> I have to dig back (or may be in the last threads where we discussed >> that). I will try to to post them here (RFC is in voting phase so no >> edition) asap. >> >> However, I totally fail to understand your reasoning. We know both >> libraries are dead. ext/Imap is almost not used anymore > > Excuse me, but *I* use ext/imap quite extensively, and I would be most > upset if you dropped it without providing an alternative. > > I would also be upset if you dropped it without ever it ever being marked > as deprecated. > Not like that PECL would be dropped, too :) However you're right, those was not deprecated, just repeatedly discussed in the past. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Zitat von Anatol Belski : Hi Stas, On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote: Hi! 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). This is part of Horde with 9 listed dependencies and 9 suggested ones, and probably also sub-dependencies. It is much less convenient than having imap right here when you run PHP. And looks like on top of that it lists PHP 7 as not supported. I'm sure there are other imap implementations, but I wouldn't be that quick in throwing out one that a lot of people may use. -- Stas Malyshev smalys...@gmail.com Horde is being developed by a some ISP, so it's mostlikely gonna support PHP7, even if not already. But this is actually what one can say regarding PHP7 compatibility with any scripts at the current stage. FWIW Horde is an open source project and not developed by any ISP. Furthermore we're actively testing against PHP 7 and already detected (and reported) a few bugs an regressions in master. Not that this matters for this discussion, just for completeness. For security tickets - there are still some on mitre, NVD and others. The point with ext/imap being available "now and here" instead of the userland implementation is of course good. However removing it has the same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it be there, unmaintained, is kinda of a black hole. And every day it grows. That's why my point is rather - link to some userland implementation instead of shipping "worky" stuff in the unknown security state. Same actually for mcrypt. Probably the same motivation can be attributed to the unavailability of libc-client and mcrypt in RHEL6. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Jan Schneider The Horde Project http://www.horde.org/ https://www.facebook.com/hordeproject -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
"Pierre Joye" wrote in message news:CAEZPtU6au_Fi2bW=e2kiqlerq4h97vhu8nkl-z9katlstef...@mail.gmail.com... On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev wrote: Hi! Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. I'm not sure - what is the dangerous part? Are you referring to some published CVEs or other reports? Then it would be useful to list them here and on the RFC. I have to dig back (or may be in the last threads where we discussed that). I will try to to post them here (RFC is in voting phase so no edition) asap. However, I totally fail to understand your reasoning. We know both libraries are dead. ext/Imap is almost not used anymore Excuse me, but *I* use ext/imap quite extensively, and I would be most upset if you dropped it without providing an alternative. I would also be upset if you dropped it without ever it ever being marked as deprecated. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Stas, On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote: > Hi! > > >> 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). > > This is part of Horde with 9 listed dependencies and 9 suggested ones, > and probably also sub-dependencies. It is much less convenient than having > imap right here when you run PHP. And looks like on top of that it lists > PHP 7 as not supported. > I'm sure there are other imap implementations, but I wouldn't be that > quick in throwing out one that a lot of people may use. -- > Stas Malyshev > smalys...@gmail.com > Horde is being developed by a some ISP, so it's mostlikely gonna support PHP7, even if not already. But this is actually what one can say regarding PHP7 compatibility with any scripts at the current stage. For security tickets - there are still some on mitre, NVD and others. The point with ext/imap being available "now and here" instead of the userland implementation is of course good. However removing it has the same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it be there, unmaintained, is kinda of a black hole. And every day it grows. That's why my point is rather - link to some userland implementation instead of shipping "worky" stuff in the unknown security state. Same actually for mcrypt. Probably the same motivation can be attributed to the unavailability of libc-client and mcrypt in RHEL6. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Wed, Feb 4, 2015 at 4:01 PM, Stanislav Malyshev wrote: > Hi! > >> However, I totally fail to understand your reasoning. We know both >> libraries are dead. ext/Imap is almost not used anymore by any major > > > What you mean by "major tool relying on imap"? I've used ext/imap > multiple times in the past, and I know others do too. Of course, there > are different libraries, so what - there are also libraries that support > HTTP or JSON, that's not the reason to remove HTTP or JSON support from > PHP. > >> tool relying on imap, Which appealing reasons do you have to force us >> to have to maintain them for the next decade? > > The same reason as for other things - it is useful and being used. If > you have reasons why not, I'm fine with considering them, but so far it > has been a bit vague. The fact that the library is not updated doesn't > mean it doesn't work. If it doesn't work - fine, let's see where it > doesn't work and decide then. ftp://ftp.cac.washington.edu/imap last release: 7/23/11 Now, considering its status (read: it is dead since 4 years), the way it works (you know it kills the process on some error right? f.e.) along other bugs (check the imap various support questions etc), and you still all good to keep it around for the next decade? Fine. It is in voting, so let see the results and move on. I however consider this as an extremely bad decision. But I do not care enough to battle it to death. Waste of time to argue about that. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! > However, I totally fail to understand your reasoning. We know both > libraries are dead. ext/Imap is almost not used anymore by any major What you mean by "major tool relying on imap"? I've used ext/imap multiple times in the past, and I know others do too. Of course, there are different libraries, so what - there are also libraries that support HTTP or JSON, that's not the reason to remove HTTP or JSON support from PHP. > tool relying on imap, Which appealing reasons do you have to force us > to have to maintain them for the next decade? The same reason as for other things - it is useful and being used. If you have reasons why not, I'm fine with considering them, but so far it has been a bit vague. The fact that the library is not updated doesn't mean it doesn't work. If it doesn't work - fine, let's see where it doesn't work and decide then. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev wrote: > Hi! > >> Libmcrypt is a dead cow but not much of a threat for now. On the other >> hand cclient is dangerous, it should have been removed long time ago >> already. > > I'm not sure - what is the dangerous part? Are you referring to some > published CVEs or other reports? Then it would be useful to list them > here and on the RFC. I have to dig back (or may be in the last threads where we discussed that). I will try to to post them here (RFC is in voting phase so no edition) asap. However, I totally fail to understand your reasoning. We know both libraries are dead. ext/Imap is almost not used anymore by any major tool relying on imap, Which appealing reasons do you have to force us to have to maintain them for the next decade? Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! > Libmcrypt is a dead cow but not much of a threat for now. On the other > hand cclient is dangerous, it should have been removed long time ago > already. I'm not sure - what is the dangerous part? Are you referring to some published CVEs or other reports? Then it would be useful to list them here and on the RFC. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 4, 2015 1:51 PM, "Stanislav Malyshev" wrote: > > Hi! > > > 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). > > This is part of Horde with 9 listed dependencies and 9 suggested ones, > and probably also sub-dependencies. It is much less convenient than > having imap right here when you run PHP. And looks like on top of that > it lists PHP 7 as not supported. > I'm sure there are other imap implementations, but I wouldn't be that > quick in throwing out one that a lot of people may use. Roundcube imap cleint has many users, other mail libraries are getting a lot of traction. It is not like our users do not move away already. For two reasons, compatibly first (many bugs in imap using c-client) and also because c-client is less and less available by default on many systems.
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 4, 2015 1:30 PM, "Stanislav Malyshev" wrote: > > Hi! > > I am kind of surprised that RFC about removing whole extensions has > "Backward Incompatible Changes" listed as "None". Really? No BC impact > whatsoever by removing imap and mcrypt? Literally nobody ever anywhere > is using it? > > > - 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. > > IIRC imap is working with PHP 7 and passes the tests on CI currently. > mcrypt seems to be enabled on CI too. So what is needed for them for 7.0? > Both extensions are relatively thin wrappers around the respective libraries. C-client for IMAP and libmcrypt for mcrypt. Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. Cheers, Pierre
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! > 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). This is part of Horde with 9 listed dependencies and 9 suggested ones, and probably also sub-dependencies. It is much less convenient than having imap right here when you run PHP. And looks like on top of that it lists PHP 7 as not supported. I'm sure there are other imap implementations, but I wouldn't be that quick in throwing out one that a lot of people may use. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! > We keep discussing how to improve security, make php safer by default, etc. > But for IMAP, you basically open the door with a big shield saying "come > in, we have free cooking and you can do almost all you want inside via this > door". This is insane. If it was only up to me I would kick it out of core > right now due to the critical issue it has. Which critical issue? I see no security issues listed in the bug DB for imap. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! I am kind of surprised that RFC about removing whole extensions has "Backward Incompatible Changes" listed as "None". Really? No BC impact whatsoever by removing imap and mcrypt? Literally nobody ever anywhere is using it? > - 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. IIRC imap is working with PHP 7 and passes the tests on CI currently. mcrypt seems to be enabled on CI too. So what is needed for them for 7.0? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
"Anatol Belski" in php.internals (Tue, 3 Feb 2015 09:11:18 +0100): >Hi Michael, > >On Tue, February 3, 2015 08:31, Michael Wallner wrote: >> On 3 Feb 2015 08:10, "Adam Harvey" wrote: > >> I understand your thoughts. How about if we do for mcrypt what we did for >> mhash, I.e. implement a compatible layer on top of openssl? I have not >> checked if it's even possible yet, just an idea that popped into mind. I >> would be willing to do this to learn more about the openssl innards, so >> I'd probably need someone else to verify my work. > >if you venture to do this, please ping. I can support you at least with >testing and maybe more. Daniel Stenberg (curl dev) happened to point to libtomcrypt today: https://github.com/libtom/libtomcrypt Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 12:37, Rowan Collins wrote: > For what it's worth, we've been running a Linux + MS SQL setup for > around 10 years, due to a previous migration from Classic ASP to PHP. We > originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4 > (previous versions didn't support nextRowset(), which made it unusable). > Both run smoothly on current Ubuntu builds with FreeTDS installed. > > While we've almost succeeded in deprecating the legacy DBs in favour of > Postgres, it could easily happen that someone is just starting down the > same route now, and would want to know what driver will work best with > PHP 7. I've still got some ASP sites, and have been using mssql in much the same way but those sites will remain with PHP5.2 and the replacements will be on the modern framework. > As others have hinted, maybe there could be a table somewhere of the > recommended drivers (and db-specific exts, where applicable) to use for > different OS/DB combinations? This could answer both "if I'm a PHP user, > which configuration should I be choosing for reasonable > future-proofing?" and "if I'm an extension developer, where should I be > contributing features?". I think third part libraries like ADOdb probably need a similar treatment. My use of mssql is via that and other legacy drivers are similarly wrapped, but tagging alternative paths there can only help, and is something I can document. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Pierre Joye wrote on 03/02/2015 09:14: On Feb 3, 2015 4:06 PM, "Lester Caine" wrote: On 03/02/15 08:44, Matteo Beccati wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. This is a bit of the problem here. There is a substantial Firebird user base who like wordpress and joomla users have no knowledge of what is going on in the background to keep their platform working. Often we don't find out about things - 'they get missed' - but similarly just treading water takes too much time today so following development on everything we do use often takes second place? I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. For mssql, most of them (while we see more and more requests from linux lately) are on windows. And mssql support has been removed with the release of 5.3.0. Since 2 years they use sqlsrv from pecl. For what it's worth, we've been running a Linux + MS SQL setup for around 10 years, due to a previous migration from Classic ASP to PHP. We originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4 (previous versions didn't support nextRowset(), which made it unusable). Both run smoothly on current Ubuntu builds with FreeTDS installed. While we've almost succeeded in deprecating the legacy DBs in favour of Postgres, it could easily happen that someone is just starting down the same route now, and would want to know what driver will work best with PHP 7. As others have hinted, maybe there could be a table somewhere of the recommended drivers (and db-specific exts, where applicable) to use for different OS/DB combinations? This could answer both "if I'm a PHP user, which configuration should I be choosing for reasonable future-proofing?" and "if I'm an extension developer, where should I be contributing features?". Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 09:14, Pierre Joye wrote: >> I wonder if ANY mssql users have noticed that they may be left out of >> PHP7 ... I suspect that may actually have a bigger user base than the >> paid for 'Interbase' yet it's got no support here. > > For mssql, most of them (while we see more and more requests from linux > lately) are on windows. And mssql support has been removed with the > release of 5.3.0. Since 2 years they use sqlsrv from pecl. I spotted the reference to using ODBC as an alternative as well which does get used for Firebird in some areas. The point perhaps is that like mysql, the information as to what IS the preferred method of working these days is not being linked to the discussion? There is useful material on a number of these 'removals' but it's all mixed up in the one thread :( Separate 'crib sheets' to support each eventual change? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 3, 2015 4:06 PM, "Lester Caine" wrote: > > On 03/02/15 08:44, Matteo Beccati wrote: > >> Marius Adrian Popa has stated to maintain both, and looks like there > >> several active users who will use that. So going by that, it's not being > >> voted on these exts. > > > > I must have missed that, sorry for the noise. > > This is a bit of the problem here. There is a substantial Firebird user > base who like wordpress and joomla users have no knowledge of what is > going on in the background to keep their platform working. Often we > don't find out about things - 'they get missed' - but similarly just > treading water takes too much time today so following development on > everything we do use often takes second place? > > I wonder if ANY mssql users have noticed that they may be left out of > PHP7 ... I suspect that may actually have a bigger user base than the > paid for 'Interbase' yet it's got no support here. For mssql, most of them (while we see more and more requests from linux lately) are on windows. And mssql support has been removed with the release of 5.3.0. Since 2 years they use sqlsrv from pecl.
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 08:44, Matteo Beccati wrote: >> Marius Adrian Popa has stated to maintain both, and looks like there >> several active users who will use that. So going by that, it's not being >> voted on these exts. > > I must have missed that, sorry for the noise. This is a bit of the problem here. There is a substantial Firebird user base who like wordpress and joomla users have no knowledge of what is going on in the background to keep their platform working. Often we don't find out about things - 'they get missed' - but similarly just treading water takes too much time today so following development on everything we do use often takes second place? I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 3, 2015 2:10 PM, "Adam Harvey" wrote: > > On 3 February 2015 at 03:11, Anatol Belski 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. We have plenty of alternative implemented in php, supporting way more things that ext/IMAP ever did. However I have a hard time to understand your argument. We keep discussing how to improve security, make php safer by default, etc. But for IMAP, you basically open the door with a big shield saying "come in, we have free cooking and you can do almost all you want inside via this door". This is insane. If it was only up to me I would kick it out of core right now due to the critical issue it has. Mcrypt is only a time bomb. It will be the same pretty soon.
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/2015 09:39, Anatol Belski wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Matteo, On Tue, February 3, 2015 09:09, Matteo Beccati wrote: > On 02/02/2015 20:21, Lester Caine wrote: > >> On 02/02/15 19:11, Anatol Belski 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. >>> >> >> I feel this is totally out of line since only people who use modules >> will have the need to retain them, but like me many of those people have >> no right to vote! >> >> I have not yet found any problem running interbase with 'master' and I >> am sure the warnings being raised simply require the assistance of >> someone who understands why a change has been made, rather than it >> being essential that we have to learn that knowledge JUST to keep an >> existing extension working. > > What about moving pdo_firebird to pecl too? Last time I checked it was > fairly broken (compared to ext/interbase). > > Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Michael, On Tue, February 3, 2015 08:31, Michael Wallner wrote: > On 3 Feb 2015 08:10, "Adam Harvey" wrote: > I understand your thoughts. How about if we do for mcrypt what we did for > mhash, I.e. implement a compatible layer on top of openssl? I have not > checked if it's even possible yet, just an idea that popped into mind. I > would be willing to do this to learn more about the openssl innards, so > I'd > probably need someone else to verify my work. > if you venture to do this, please ping. I can support you at least with testing and maybe more. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 02/02/2015 20:21, Lester Caine wrote: On 02/02/15 19:11, Anatol Belski 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. I feel this is totally out of line since only people who use modules will have the need to retain them, but like me many of those people have no right to vote! I have not yet found any problem running interbase with 'master' and I am sure the warnings being raised simply require the assistance of someone who understands why a change has been made, rather than it being essential that we have to learn that knowledge JUST to keep an existing extension working. What about moving pdo_firebird to pecl too? Last time I checked it was fairly broken (compared to ext/interbase). Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
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 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
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/02/2015 08:10, Adam Harvey a écrit : > To explain my -1s: > > - ext/imap and ext/mcrypt: while I realise that the underlying > libraries are dead, This means, if we want to keep them, we have to take ownership and maintain those libraries. Do you really want to do this ? > these extensions are too widely used to straight up remove them, For mcrypt, I think lot of project use it as optional (perhaps, at least, because a Enterprise distro doesn't provide it) Recently phpMyAdmin have switch to openssl first. Remember, if it is dropped from PHP, it will be available as a pecl extension. We need a strong signal about "don't use this dead cow", and I think, moving it to pecl is such a signal. Remi -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlTQf2kACgkQYUppBSnxahhnhwCeIsgARB8lYW3D6bfGufbgEydi fkoAoPfs69rx5gQlBN/ev+YDNWYxQaKd =KviN -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 3 Feb 2015 08:10, "Adam Harvey" wrote: > > On 3 February 2015 at 03:11, Anatol Belski 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. I understand your thoughts. How about if we do for mcrypt what we did for mhash, I.e. implement a compatible layer on top of openssl? I have not checked if it's even possible yet, just an idea that popped into mind. I would be willing to do this to learn more about the openssl innards, so I'd probably need someone else to verify my work. > > - 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). > > 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. Is this really used? It's been here before Apache2handler, bit my guess is, just because filters were new and cool. > - 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? Sendmail mailfilter API. I did one odd fix in the past, but the bug was old, and the reporter didn't come back. > - 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. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 3 February 2015 at 03:11, Anatol Belski 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. - 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). 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. - 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? - 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. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Andrea, On Mon, February 2, 2015 23:54, Andrea Faulds wrote: > Hi Danack, > > >> On 2 Feb 2015, at 22:50, Dan Ackroyd wrote: >> >> >> On 2 February 2015 at 19:11, Anatol Belski >> wrote: >> >>> The voting ends on 2015-02-09 at 21:00 CET. >>> >> >> This is a ridiculously short voting period for a major decision. >> Although the minimum voting time for an RFC is one week, that should >> only be used in extremis. > > I wouldn’t say one week is “in extremis” - it’s reasonable for small, > self-contained, BC break-less new features. Although at least 10 days is > usually better. This topic was spoken long before the discussion was started. It's also not that the subjects would be erased from existence, they'll be moved to a separate branch, that's all. Furthermore, they're available for a while in the lower branches (non PHP7 ported, so almost the same state). And anyone interested is free to resurrect something or put into PECL. > > That being said, I agree. This kind of thing shouldn’t be taken lightly, > and this RFC should have a longer voting period. > >> The people affected by this decision are not likely to read PHP >> internals every day or even every week. > > Yeah, I agree here. The fact there’s not been much discussion attests to > that. > > +1 > > We could hold this open far much longer, that's true. However that obviously wouldn't help us to find maintainers for that stuff. On the other hand - it would really bring PHP7 forward getting rid of things where everyone agrees. As not having to do --disable-all all the time is a certain plus. One needs not much time to check that. I'd really suggest to put a "yes" or "no" at this point and have it done. Whereby some "no" from an active developer in this case IMHO would mean not just "no, that should stay in the core", but "yes, i'll help to port and maintain it". However nobody is forced to mean or guarantee that, just that at the end we can end up with some non ported pieces of core. IMHO we should kick out what obviously doesn't fit anymore and move forward, as the PHP7 deadline is quite tight. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Danack, > On 2 Feb 2015, at 22:50, Dan Ackroyd wrote: > > On 2 February 2015 at 19:11, Anatol Belski wrote: >> The voting ends on 2015-02-09 at 21:00 CET. > > This is a ridiculously short voting period for a major decision. > Although the minimum voting time for an RFC is one week, that should > only be used in extremis. I wouldn’t say one week is “in extremis” - it’s reasonable for small, self-contained, BC break-less new features. Although at least 10 days is usually better. That being said, I agree. This kind of thing shouldn’t be taken lightly, and this RFC should have a longer voting period. > The people affected by this decision are not likely to read PHP > internals every day or even every week. Yeah, I agree here. The fact there’s not been much discussion attests to that. +1 -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 2 February 2015 at 19:11, Anatol Belski wrote: >The voting ends on 2015-02-09 at 21:00 CET. This is a ridiculously short voting period for a major decision. Although the minimum voting time for an RFC is one week, that should only be used in extremis. The people affected by this decision are not likely to read PHP internals every day or even every week. This voting period should be left open as long as possible, probably as close to PHP 7's alpha date as feasible. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski wrote: Mcrypt might be dead, but removing it would be a huge BC break. There was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest that instead of removal. >>> that sounds plausible, but the same one could say about mapping to be >>> removed regex to pcre. If anything of that is going to be happening, so >>> I >>> would welcome another RFC and implementation. >>> >> >> Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was >> never deprecated and is extremely wide-spread in PHP code (that does >> encryption) today. >> > yeah, looking at the openssl you've mentioned, and which was vulnerable to > any possible attacks last years, and has fixed those ... Asking myself, > how a library which wasn't updated since like eight years does feel :) Can > it still provide that really secure encryption? And should one provide > something like that as a secure solution? > > Comparing with regex I meant, one could provide a replacing API. Just > where with regex it's more like functionality breach (whereby security as > well, as that lib wasn't revisited maybe for much longer than mcrypt), > with mcrypt it's a security weakness we would still try to sell for safe. > Well, obviously mcrypt *has* to go away at some point - there's no doubt about it. I'm just saying it would be a massive BC break if that happens with no prior deprecation. If somebody has the motivation to make the userland API bind to ext/openssl under the hood, that's just a bonus in at least depending on maintained code. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Mon, February 2, 2015 22:39, Andrey Andreev wrote: > Hi, > > > On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski > wrote: > >> On Mon, February 2, 2015 20:30, Andrey Andreev wrote: >> >>> Oh, forgot one thing ... >>> >>> >>> >>> Mcrypt might be dead, but removing it would be a huge BC break. There >>> was some talk of binding mcrypt_*() functions to ext/openssl - I'd >>> suggest that instead of removal. >>> >> that sounds plausible, but the same one could say about mapping to be >> removed regex to pcre. If anything of that is going to be happening, so >> I >> would welcome another RFC and implementation. >> > > Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was > never deprecated and is extremely wide-spread in PHP code (that does > encryption) today. > yeah, looking at the openssl you've mentioned, and which was vulnerable to any possible attacks last years, and has fixed those ... Asking myself, how a library which wasn't updated since like eight years does feel :) Can it still provide that really secure encryption? And should one provide something like that as a secure solution? Comparing with regex I meant, one could provide a replacing API. Just where with regex it's more like functionality breach (whereby security as well, as that lib wasn't revisited maybe for much longer than mcrypt), with mcrypt it's a security weakness we would still try to sell for safe. Regards Anatol. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski wrote: > On Mon, February 2, 2015 20:30, Andrey Andreev wrote: >> Oh, forgot one thing ... >> >> >> Mcrypt might be dead, but removing it would be a huge BC break. There >> was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest >> that instead of removal. >> > that sounds plausible, but the same one could say about mapping to be > removed regex to pcre. If anything of that is going to be happening, so I > would welcome another RFC and implementation. > Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was never deprecated and is extremely wide-spread in PHP code (that does encryption) today. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Uwe,
On Mon, February 2, 2015 21:20, Uwe Schindler wrote:
> Hi,
>
>
> I gave my votes (where I can talk about). I am still maintaining the
> NSAPI
> SAPI. It does not meant that its dead if no commits were made. NSAPI
> upstream API just did not change since years, so why change a running
> system?
>
> The current version of this SAPI (5.6) runs perfectly with MediaWiki and
> several CMS systems on latest Oracle iPlanet server in production. The
> information about NSAPI you gave ("The developers of iPlanet @Oracle
> wrote back, that they're not intended to support this SAPI starting from
> PHP7
> onwards.") is not applicable, because people from Sun/Oracle never
> provided any support or this extension - you should have asked the
> maintainer (me). Oracle just recommends fcgi, because it might be more
> stable if you use non-threadsafe extensions, but otherwise the server is
> perfectly stable and very fast. Oracle employees only helped with one
> patch, otherwise it was mostly (re-)written by me. In addition, the server
> works perfectly fine on Ubuntu 14.04, so it will also run on Debian. It
> can be downloaded with Oracle OTN license, header files are included. You
> can compile PHP 5.6 with it as documented:
> http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserve
> r-525365.html
>
> If there are changes needed in the SAPI for PHP 7, I can take care, I
> just have not looked into it. It should not be a problem for me to update
> it, unless significant changes in the PHP API occurred since my last
> commit (yes, I am a bit inactive, but still following the development).
>
yeah, I saw your reply previously that it's worky with PHP5, however
couldn't test (whereby it turned out iPlanet is available not only for
SunOS). But then I had the reply from the @Oracle devs and thought it's
were cleared. Please check what happened to Apache SAPI (just to estimate
the efforts), there's quite some change after the phpng and TLS merge. If
you think it'd be acceptable for you to port and maintain in the ufture,
so lets restart the vote right now and exclude sapi/nsapi.
Thanks.
Anatol.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi,
I gave my votes (where I can talk about). I am still maintaining the NSAPI
SAPI. It does not meant that its dead if no commits were made. NSAPI upstream
API just did not change since years, so why change a running system?
The current version of this SAPI (5.6) runs perfectly with MediaWiki and
several CMS systems on latest Oracle iPlanet server in production. The
information about NSAPI you gave ("The developers of iPlanet @Oracle wrote
back, that they're not intended to support this SAPI starting from PHP7
onwards.") is not applicable, because people from Sun/Oracle never provided any
support or this extension - you should have asked the maintainer (me). Oracle
just recommends fcgi, because it might be more stable if you use non-threadsafe
extensions, but otherwise the server is perfectly stable and very fast. Oracle
employees only helped with one patch, otherwise it was mostly (re-)written by
me. In addition, the server works perfectly fine on Ubuntu 14.04, so it will
also run on Debian. It can be downloaded with Oracle OTN license, header files
are included. You can compile PHP 5.6 with it as documented:
http://www.oracle.com/technetwork/java/webtier/downloads/iplanet-webserver-525365.html
If there are changes needed in the SAPI for PHP 7, I can take care, I just have
not looked into it. It should not be a problem for me to update it, unless
significant changes in the PHP API occurred since my last commit (yes, I am a
bit inactive, but still following the development).
Uwe
-
Uwe Schindler
theta...@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
> -Original Message-
> From: Anatol Belski [mailto:anatol@belski.net]
> Sent: Monday, February 02, 2015 8:45 PM
> To: Andrey Andreev
> Cc: Nikita Popov; Anatol Belski; PHP internals
> Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
> SAPIs and extensions
>
> On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
> > Oh, forgot one thing ...
> >
> >
> > Mcrypt might be dead, but removing it would be a huge BC break. There
> > was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
> > that instead of removal.
> >
> that sounds plausible, but the same one could say about mapping to be
> removed regex to pcre. If anything of that is going to be happening, so I
> would welcome another RFC and implementation.
>
> Regards
>
> Anatol
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Mon, February 2, 2015 20:30, Andrey Andreev wrote: > Oh, forgot one thing ... > > > Mcrypt might be dead, but removing it would be a huge BC break. There > was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest > that instead of removal. > that sounds plausible, but the same one could say about mapping to be removed regex to pcre. If anything of that is going to be happening, so I would welcome another RFC and implementation. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Mon, February 2, 2015 20:15, Nikita Popov wrote: > On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski > wrote: > > >> Hi, >> >> >> 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. >> >> >> Regards >> >> >> Anatol >> >> > > I get the motivation to drop dead SAPIs or extensions that require > unmaintained libraries. > > However this list also contains a number of exts like ext/interbase where > people have explicitly stated in the discussion that the extension is > still supported and will be ported to PHP 7. Why do we vote to remove > them? Or did I misunderstand something? > yeah, frankly I was waiting for at least one voice for these extensions to exclude them from the vote (and I was also explicitly sending a reminder for this RFC last week). And I anyway didn't believe them to be voted "yes" because it's mentioned they're going to be supported. Now interbase and pdo are excluded from the voting, as per multiple requests. It's not 21:00 CET yet, so hereby the voting is started. Thanks. Anatol. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Oh, forgot one thing ... Mcrypt might be dead, but removing it would be a huge BC break. There was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest that instead of removal. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, On Mon, Feb 2, 2015 at 9:15 PM, Nikita Popov wrote: > On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski wrote: > >> Hi, >> >> 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. >> >> Regards >> >> Anatol >> > > I get the motivation to drop dead SAPIs or extensions that require > unmaintained libraries. > > However this list also contains a number of exts like ext/interbase where > people have explicitly stated in the discussion that the extension is still > supported and will be ported to PHP 7. Why do we vote to remove them? Or > did I misunderstand something? > > Nikita I'd like to ask the same thing about oci8 and pdo_oci. I haven't dealt with Oracle in awhile now, but last time I had to - it was still in PECL, so ... why and where would it get removed from? Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 02/02/15 19:11, Anatol Belski 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. I feel this is totally out of line since only people who use modules will have the need to retain them, but like me many of those people have no right to vote! I have not yet found any problem running interbase with 'master' and I am sure the warnings being raised simply require the assistance of someone who understands why a change has been made, rather than it being essential that we have to learn that knowledge JUST to keep an existing extension working. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski wrote: > Hi, > > 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. > > Regards > > Anatol > I get the motivation to drop dead SAPIs or extensions that require unmaintained libraries. However this list also contains a number of exts like ext/interbase where people have explicitly stated in the discussion that the extension is still supported and will be ported to PHP 7. Why do we vote to remove them? Or did I misunderstand something? Nikita
[PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi, 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. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
