Re: [PHP-DEV] Bundling modern extensions
Am 09.06.2011 20:11, schrieb Michael Wallner: In the past many developers did not feel comfy enough with the pecl_http extension. It had been proposed for inclusion in the core distribution for a few times, but people always had doubts about the API etc. i do not understand why Another major addition will be the choice of request handling library http\Request should use. libcurl, neon and serf are on the table currently. sounds like php-namespaces are introduced here even for people usig them NOT becuase of the braindead \ Anyway, if people want to take part in architecting the future of this extension, they are more than welcome. I already invited you to participate, but you did not answer what want you hear from me? let the api fuck in peace or you risk that the extension will not used in the future because you force all users to totally change their projects with the fear that 5 years later 3.0.0 breaks all baackward compatibility again signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On 9 Jun 2011 20:11, Michael Wallner m...@php.net wrote: I started the rewrite of the extension, because it had one really big drawback, namely that message bodies where implemented as memory chunk instead of streams. The next major headache caused the confusion which the HttpResponse class was responsible for. Another major addition will be the choice of request handling library http\Request should use. libcurl, neon and serf are on the table currently. I'd to strongly suggest to keep using libcurl, it is the most well maintained and OSS-friendly library. It also happens to be very closed to the standard, in this http. Cheers,
Re: [PHP-DEV] Bundling modern extensions
On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner m...@php.net wrote: I started the rewrite of the extension, because it had one really big drawback, namely that message bodies where implemented as memory chunk instead of streams. The next major headache caused the confusion which the HttpResponse class was responsible for. Another major addition will be the choice of request handling library http\Request should use. libcurl, neon and serf are on the table currently. Btw, maybe you did not notice it but neon is GPL... Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Fri, 10 Jun 2011 11:29:44 +0200, Pierre Joye wrote: On Thu, Jun 9, 2011 at 8:11 PM, Michael Wallner m...@php.net wrote: I started the rewrite of the extension, because it had one really big drawback, namely that message bodies where implemented as memory chunk instead of streams. The next major headache caused the confusion which the HttpResponse class was responsible for. Another major addition will be the choice of request handling library http\Request should use. libcurl, neon and serf are on the table currently. Btw, maybe you did not notice it but neon is GPL... Looks like it's licensed under LGPLv2: http://svn.webdav.org/repos/projects/neon/trunk/src/COPYING.LIB It doesn't seem to perform too well in the general way, anyways... Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 10.06.11 11:20 schrieb Reindl Harald unter h.rei...@thelounge.net: let the api fuck in peace or you risk that the extension will not used in the future because you force all users to totally change their projects with the fear that 5 years later 3.0.0 breaks all baackward compatibility again Please change your tone. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
As far as I can see there are very few extension that are really needed in the core, the main problem comes from distributions changing the methods that PECL works or the core works e.g. Ubuntu you need to install the -dev version in order for extension to be compiled/installed Gentoo you need to either write your own ebuild for a pecl extension, hope one exists, or go through lots of hoops to get them to work the problem we have is getting this across to either distribution builders, or giving them a set of standards to follow so that the process of building PECL extensions is easy to follow from the 'user' perspective, you should be able to follow the install guides on pecl.php instead of searching for your distributions special method // then it comes to things that arent maintained in PECL and then get used, in those instances, there is an even bigger reason not to incoroprate it into the core, if something no longer works because it isnt maintained, putting that into the core is shooting ourselves in the foot, the best thing that can happen with those extensions, is for you to post a bug report, if there is no response, it must be dead, and take that as a sign that you need to re-write your own code \\ taking the attitude of shouting odds because your view isnt being listening to, is not the way to go, all you do is alienate yourself, and people are unlikelly to listen to you, re-evaluate what your trying to say and then listen to the views of others, you will realize that the view to incoroprate dead things into the core on the hope that it will suddenly start working is not going to happen, your best option is to take the mantle, and fork that project, and make it work, there is proberlly a way of telling pecl that yours is then the one to use On Fri, Jun 10, 2011 at 11:50 AM, Lars Strojny l...@strojny.net wrote: Am 10.06.11 11:20 schrieb Reindl Harald unter h.rei...@thelounge.net: let the api fuck in peace or you risk that the extension will not used in the future because you force all users to totally change their projects with the fear that 5 years later 3.0.0 breaks all baackward compatibility again Please change your tone. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote: As far as I can see there are very few extension that are really needed in the core, the main problem comes from distributions changing the methods that PECL works or the core works e.g. Ubuntu you need to install the -dev version in order for extension to be compiled/installed Gentoo you need to either write your own ebuild for a pecl extension, hope one exists, or go through lots of hoops to get them to work Both have many popular PECL modules available. the problem we have is getting this across to either distribution builders, or giving them a set of standards to follow so that the process of building PECL extensions is easy to follow from the 'user' perspective, you should be able to follow the install guides on pecl.php instead of searching for your distributions special method http://php.net/install.pecl In general when doing system adminstration one should know the system. When leaving the package manager world even more. But besides that: Feel free to open bug reports about missing info, or even better go to edit.php.net and improve it :-) // then it comes to things that arent maintained in PECL and then get used, in those instances, there is an even bigger reason not to incoroprate it into the core, if something no longer works because it isnt maintained, putting that into the core is shooting ourselves in the foot, the best thing that can happen with those extensions, is for you to post a bug report, if there is no response, it must be dead, and take that as a sign that you need to re-write your own code We don't change our core APIs too often and even though many core contributors don't test all features many of them are used successfully in the outside work and just work. Sometimes bug reports for strange things come in and are being fixed. Can be hard to define what unmaintained means ... \\ taking the attitude of shouting odds because your view isnt being listening to, is not the way to go, all you do is alienate yourself, and people are unlikelly to listen to you, re-evaluate what your trying to say and then listen to the views of others, you will realize that the view to incoroprate dead things into the core on the hope that it will suddenly start working is not going to happen, your best option is to take the mantle, and fork that project, and make it work, there is proberlly a way of telling pecl that yours is then the one to use We usually are quite happy with people taking over. snmp for instance didn't see much love for a few years, now some new guy came in, had some patches became maintainer and snmp in 5.4 will have tons of changes and improvements. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Fri, Jun 10, 2011 at 12:50 PM, Lars Strojny l...@strojny.net wrote: Please change your tone. +1! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Fri, 10 Jun 2011 13:39:34 +0200, Johannes Schlüter johan...@schlueters.de wrote: On Fri, 2011-06-10 at 12:03 +0100, Keloran wrote: As far as I can see there are very few extension that are really needed in the core, the main problem comes from distributions changing the methods that PECL works or the core works e.g. Ubuntu you need to install the -dev version in order for extension to be compiled/installed Gentoo you need to either write your own ebuild for a pecl extension, hope one exists, or go through lots of hoops to get them to work Both have many popular PECL modules available. If there is a stable version upstream, I add and maintain ebuilds for pretty much every PECL package that is requested on bugs.gentoo.org. Creating your own ebuild is also often as difficult as copying and renaming an existing PECL package. Also, since PEAR_PEAR-1.9.2-r2 you should be able to just use pecl. Of course, if you do this, you have to make sure your system remains sane. As the maintainer of PHP on Gentoo, I prefer extensions in pecl over being bundled with php. -- Ole Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Sun, 05 Jun 2011 13:37:36 +0200, Reindl Harald wrote: http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension In the past many developers did not feel comfy enough with the pecl_http extension. It had been proposed for inclusion in the core distribution for a few times, but people always had doubts about the API etc. I started the rewrite of the extension, because it had one really big drawback, namely that message bodies where implemented as memory chunk instead of streams. The next major headache caused the confusion which the HttpResponse class was responsible for. Another major addition will be the choice of request handling library http\Request should use. libcurl, neon and serf are on the table currently. Anyway, if people want to take part in architecting the future of this extension, they are more than welcome. I already invited you to participate, but you did not answer. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bundling modern extensions
Please don't forget that it's possible to host your database apart from your main code. Mongolab[1] While this is technically true, and as much as I love MongoDb, for all practical purposes this isn't really useful. The latency on these sorts of connections is generally totally unacceptable. Also, I'm inclined to agree that bundling won't have a large effect on whether hosts include certain modules; in my experience they seem to be fairly aggressive about culling modules that they don't like, or don't think will be useful. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface Either that, or a PHP equivalent of Cython or Pyrex. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 07.06.2011 11:32, schrieb David Muir: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. i know that I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface where is the real difference to a userland-library as PEAR and the thousand other which exists and will we ever see a solution for extensions wich is SECURE? there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On 07/06/11 18:40, Reindl Harald wrote: Am 07.06.2011 11:32, schrieb David Muir: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. i know that I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface where is the real difference to a userland-library as PEAR and the thousand other which exists and will we ever see a solution for extensions wich is SECURE? there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? Python has ctypes. How did it solve the security problems? What exactly are the security issues? I'm really trying to figure out where you're coming from. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Tyrael
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs i...@tyrael.hu wrote: On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 4:59 PM, Martin Scotta martinsco...@gmail.comwrote: Martin Scotta On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs i...@tyrael.hu wrote: On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? I didn't intended to use that to block your feature request. I've just show that there are people ran php installs with enable_dl = On personally I wouldn't mind if we would drop the support for the dl, but thats offtopic here. Tyrael
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Tue, Jun 7, 2011 at 6:32 AM, David Muir davidkm...@gmail.com wrote: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface Either that, or a PHP equivalent of Cython or Pyrex. Cython or Pyrex are good examples of what I meant. I'm not sure about the PNI Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 07.06.2011 16:59, schrieb Martin Scotta: Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? 2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 httpd-2.2.19-2.fc14.rh.20110526.x86_64 apr-1.4.5-1.fc14.rh.20110522.x86_64.rpm mod_security-2.6.0-3.fc14.rh.20110526.x86_64 php-suhosin-0.9.32.1-13.fc14.rh.20110526.x86_64 mysql-server-5.5.13-2.fc14.rh.20110601.x86_64 phpMyAdmin-3.4.2-2.fc14.rh.20110607.noarch.rpm disable_functions: popen, pclose, exec, passthru, shell_exec, system, proc_open proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink so please keep in mind that there are users/admins which are really knowing what they do and try not introduce cool features / defaults while bypassing security with them only for braindead users thinking enable all you can get is funny a well configured machine has ALL disabled / uninstalled which is not really needed signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
My reasoning is simple. The key for bundling extensions is to have them available for most hosting solutions. If a shared host provides support for mongodb, then he will most likely enable the mongodb extension in php, if he knows what he is doing. The same applies for all other non core critical features but more from an architecture point of view. Please don't forget that it's possible to host your database apart from your main code. Mongolab[1], for example, offers MongoDB hosting, so shared hosts that have the MongoDB extension enabled could easily use their free tier on cheap hosting (at the cost of latency, of course). Couch.io[2] used to offer free trial/sandbox hosting of CouchDB, similarly (but there was no stable CouchDB extension last time I checked), but I'm not sure if Couchbase (to which couch.io now points) does. The point is that you don't need to have the target service available on the PHP-hosting-machine in order to make use of the technology. [1] https://mongolab.com/ [2] http://www.couchbase.com/ S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 06/06/2011 10:56 AM, Johannes Schlüter wrote: On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote: The only way, currently, that projects can predict what a given host will have installed is bundled in core PHP. If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. While that rule is not true by far. I never said it was a *good* rule. Just that it's the least bad we have right now. In the Drupal project (my home turf) we regularly struggle with debating if we can rely on a certain extension or not given that it's so hard to predict host behavior. Even among dedicated servers, many of my clients wrinkle their brows in confusion when I talk about installing a PECL module more complex than APC. We really do need some predictability in this market. Unless we start a certification program (PHP Certified Hoster .. demanding some specific features etc.) there's little we can do. And I doubt we want to do that ;-) If I had the time I'd consider it, frankly. We did manage to force the issue with PHP 5.2 with the GoPHP5 project. I once considered expanding its scope but never really had the time/energy to drive it. One day[tm] I plan to make all this data public with a simple query interface. I'd also be interested in adding such a data collection to other software. If you're interested feel free to contact me of list. johannes I am interested, actually. Stand by. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
2011/6/7 Johannes Schlüter johan...@schlueters.de: That's why there are package managers or the windows Installer bundling some PECL stuff (or MSFT's Web Installer thingy) The msft thingy as you call it does not support update and is a simple wrapper around our own installer (which uses MSI). We (php-win) would like however to provide such tool on windows, to install the binaries for php's extension as well as updating php itself, totally or what is necessary (updated library or extension for example, besides the main php releases). That's on the list for the next months. Cheers. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 6/5/11 7:54 AM, Ferenc Kovacs wrote: just for the record, I agree with Pierre on this one. our userbase has two distinct group: those who are using shared hosting and usually use some third party cms or write their own crappy suboptimal code, and those who use php to build bleeding edge custom product (either on top of some 3rd party framework, or on their own). for the first group, they doesn't configure their installation, but their hosting providers do that for them. those providers usually has custom configuration or compilation of php, because by default, there are many ways where one user in the shared environment can blow up or compromise the full server. so for those people, including more stuff in the core means change, which they have to adapt, and migrate (add more disable_ to the vhost configs or recompile php without the newly included stuff). btw. usually the general cms solutions targets the standard installations, so they won't use stuff like mongodb. at least not as a requirement in their core functionalities. As someone who deals mostly with managed hosting (not necessarily shared but a server where the customer doesn't have root), that's an important consideration. For anyone working in the non-custom CMS world (Drupal, WP, Joomla, etc.), knowing the baseline you can expect from a general PHP host is critically important. Drupal, for instance, considered but rejected making SQLite a requirement for Drupal 7 for some low-level bootstrapping logic because we found a few hosts that we did want to continue to support that didn't bundle it. The only way, currently, that projects can predict what a given host will have installed is bundled in core PHP. If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. For me the question isn't should we bundle memcached in PHP core, it's how do we establish an expected baseline of PHP components that developers can reasonably expect will be available, and what should be in that? Right now, that baseline is bundled in core. This question is completely irrelevant to people who always have root on their dev and production servers, but they are, frankly, a minority of PHP-using domains out there. For those who deal in the mass-market, knowing that baseline is critical. So how do we establish that baseline if not by bundling an extension in core? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield la...@garfieldtech.comwrote: On 6/5/11 7:54 AM, Ferenc Kovacs wrote: just for the record, I agree with Pierre on this one. our userbase has two distinct group: those who are using shared hosting and usually use some third party cms or write their own crappy suboptimal code, and those who use php to build bleeding edge custom product (either on top of some 3rd party framework, or on their own). for the first group, they doesn't configure their installation, but their hosting providers do that for them. those providers usually has custom configuration or compilation of php, because by default, there are many ways where one user in the shared environment can blow up or compromise the full server. so for those people, including more stuff in the core means change, which they have to adapt, and migrate (add more disable_ to the vhost configs or recompile php without the newly included stuff). btw. usually the general cms solutions targets the standard installations, so they won't use stuff like mongodb. at least not as a requirement in their core functionalities. As someone who deals mostly with managed hosting (not necessarily shared but a server where the customer doesn't have root), that's an important consideration. For anyone working in the non-custom CMS world (Drupal, WP, Joomla, etc.), knowing the baseline you can expect from a general PHP host is critically important. Drupal, for instance, considered but rejected making SQLite a requirement for Drupal 7 for some low-level bootstrapping logic because we found a few hosts that we did want to continue to support that didn't bundle it. The only way, currently, that projects can predict what a given host will have installed is bundled in core PHP. If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. For me the question isn't should we bundle memcached in PHP core, it's how do we establish an expected baseline of PHP components that developers can reasonably expect will be available, and what should be in that? Right now, that baseline is bundled in core. This question is completely irrelevant to people who always have root on their dev and production servers, but they are, frankly, a minority of PHP-using domains out there. For those who deal in the mass-market, knowing that baseline is critical. So how do we establish that baseline if not by bundling an extension in core? the in core can mean different things. as I mentioned before, the distributors package the php stuff on their own way. so for example debian packages curl, gd, imap, intl, ldap, mysql separately when we have this in core, and they also have common pecl modules as php packages. event stuff like mysql isn't enabled by default for example, obviously almost every hosting provider will install that. Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote: The only way, currently, that projects can predict what a given host will have installed is bundled in core PHP. If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. While that rule is not true by far. Shared hosting usually does not offer com_dotnet, gettext, interbase, ldap, mssql, oci8, odbc, pdo_dblib, pdo_firebird, pdo_oci, pdo_odbc, pdo_pgsql, pgsql, recode, snmp, sybase_ct I know many which don't provide ftp, gmp, imap, mbstring, openssl, phar, shmop, sysvmsg, sysvsem, sysvshm, wddx, xmlrpx, zip, zlib Sometimes for good reasons (a firebird extension makes no sense if you don't provide firebird) sometimes for strange reasons (i don't want my customers to waste CPU/network) so in the end bundling is no guarantee. and btw. I also now shared hosters which offer PECL stuff after customers demanded it. Unless we start a certification program (PHP Certified Hoster .. demanding some specific features etc.) there's little we can do. And I doubt we want to do that ;-) So the guessing game is hard. what I started some years ago was collecting some statistics which is reported by installers from PHP applications. The first app I'm using this with is phpMyFAQ, but phpBB3 meanwhile has a similar feature. By these statistics I can tell that just 1.5% of the people installing phpMyFAQ are having APC installed, Zend Optimizer is available more often, 65.7%. 98.7% have the tokenizer extension enabled. Roughly 3/4 are claiming to use hosting companies. (all only counting where users agreed to send the information, collecting since June 2007, while the collection logic was broken for a few months now ...) One day[tm] I plan to make all this data public with a simple query interface. I'd also be interested in adding such a data collection to other software. If you're interested feel free to contact me of list. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield la...@garfieldtech.com wrote: For me the question isn't should we bundle memcached in PHP core, it's how do we establish an expected baseline of PHP components that developers can reasonably expect will be available, and what should be in that? Right now, that baseline is bundled in core. Having memcached, mongodb or whatever other similar extensions in core won't make these hosters provide memcache or mongodb support, not the waste majority. However there are already hosters providing mongodb or couchdb support and they all take care of the respective extensions using the non core modules (pecl or github). That's why I really like to differentiate sqlite/http and similar extensions from extensions being a client for a given server or service. Mysql is still a de facto standard but that's something we cannot really compare to any of the current nosqlco technologies, from a usage or spread point of view. Dedicated hosting are usually the place where they are used (virtualized or not). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I can't think of a statement I would disagree more with. These are exactly the ones we should be bundling. My reasoning is simple. The key for bundling extensions is to have them available for most hosting solutions. If a shared host provides No. Join the real world again. Anything not in vanilla PHP is hard to install because it causes more work in maintenance of the server, and increases the risk of fuckups etc etc Can you please stay at a technical level? Thanks. I'm not going to argue if my experiences, feedbacks and interactions with any kind of projects is larger or longer than yours (it is as a matter of fact but who cares?). But one thing is sure, all distributions do include mongodb, memcache(d), couchdb, etc. If you can't run an apt-get install memcached (non core), just like you run apt-get install pdo_mysql (core), then there is something intrinsically wrong in your system. Or it means YOU DO NOT HAVE ROOT. Just because the distributions OFFER the extensions does not mean that users have ACCESS to them. Not everyone has complete control over their boxes, or sysadmins who are willing to update configurations. If the functionality were available as part of core, developers would simply have access, regardless of distribution and permissions. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: It sounds like persons doing these inquiries do not know PHP, its environment and how it works, neither they know that 99% of the linux distribution (and in some extend on windows too) provide most of the modern extensions with their standard distribution. I disagree. Most distributions have a stock install that offers _less_ than a vanilla PHP install, and anything else has to be installed via the system's package manager, or via PECL (assuming you have the rights to install pecl extensions in the first place). So, while they may OFFER them, they're not available BY DEFAULT. For general purposes extensions or really globally useful (as any almost all php users will have a use), PHP's rapid rise in popularity initially was because it DID bundle the kitchen sink, and more, by default. Why was MySQL so popular with PHP in the early days (and still!)? Because it was available by default. Why are so many folks still not using an opcode cache, despite people saying for close to a decade that it should be the first stop towards improving performance? Because PHP has _never_ bundled one by default. Why is JSON so ubiquitous for interacting with PHP services? Because it's available by default. My point is that perhaps PHP has missed the boat a bit by moving everything into extensions. Perhaps if an extension is particularly popular, it should be incorporated into core. But let USAGE drive that, not the opinions of individuals on @internals. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Sat, 4 Jun 2011, Andi Gutmans wrote: For starters I would bundle ext/mongo which is very well maintained; see if we can get thrift_protocol contributed to PECL and included (support HBase and Cassdandra and used by a few PHP SDKs integrating with these data stores). I generally agree, but regarding the MongoDB extension I am a bit in doubt. There is a lot of changes (new things, but also bug fixes), and just by having it in PECL it makes it (a bit easier) to update. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: My point is that perhaps PHP has missed the boat a bit by moving everything into extensions. Perhaps if an extension is particularly popular, it should be incorporated into core. But let USAGE drive that, not the opinions of individuals on @internals. I cannot disagree than with this statement. PHP is one of the language with the most connectivity solutions, fast adoption of new technologies, etc. Why? Because the language itself is relatively stable while its extensions are created every day for every possible use. However it seems that you forgot to consider what I said here a couple of times already. Having one nosql extension in core won't make hosters make the respective server side infrastructure available. How many hosters provide firebird? DB2? Only sqlserver is part of the standard windows offers but that's due to some different factors. That's why we should differentiate general purposes extensions like pecl's http and driver like mongo. so why mysql ext is int core? it's as specific as mongo, isn't? It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Mon, Jun 6, 2011 at 11:40 PM, Martin Scotta martinsco...@gmail.comwrote: Martin Scotta On Mon, Jun 6, 2011 at 2:01 PM, Pierre Joye pierre@gmail.com wrote: On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: My point is that perhaps PHP has missed the boat a bit by moving everything into extensions. Perhaps if an extension is particularly popular, it should be incorporated into core. But let USAGE drive that, not the opinions of individuals on @internals. I cannot disagree than with this statement. PHP is one of the language with the most connectivity solutions, fast adoption of new technologies, etc. Why? Because the language itself is relatively stable while its extensions are created every day for every possible use. However it seems that you forgot to consider what I said here a couple of times already. Having one nosql extension in core won't make hosters make the respective server side infrastructure available. How many hosters provide firebird? DB2? Only sqlserver is part of the standard windows offers but that's due to some different factors. That's why we should differentiate general purposes extensions like pecl's http and driver like mongo. so why mysql ext is int core? it's as specific as mongo, isn't? It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? that would be very bad from the security pov. including an extension should be always explicit. Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Mon, 2011-06-06 at 12:53 -0400, Matthew Weier O'Phinney wrote: But one thing is sure, all distributions do include mongodb, memcache(d), couchdb, etc. If you can't run an apt-get install memcached (non core), just like you run apt-get install pdo_mysql (core), then there is something intrinsically wrong in your system. Or it means YOU DO NOT HAVE ROOT. Just because the distributions OFFER the extensions does not mean that users have ACCESS to them. Not everyone has complete control over their boxes, or sysadmins who are willing to update configurations. If the functionality were available as part of core, developers would simply have access, regardless of distribution and permissions. Which won't change a bit if we bundle it. Distributors already make stuff shared in different packages we enable(!) by default. (sqlite, xml stuff, ...) So the sysadmin already has to choose. And the choice is little affected by what we call default but what either the admin's preferences or some requirement document coming from somewhere ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Mon, 2011-06-06 at 18:40 -0300, Martin Scotta wrote: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? No sane sysadmin would allow this. Executing random machine code coming from some random user. Mind that this will affect all virtual hosts etc. Besides that: It probably might eventually work on Windows where there is a relatively homogeneous environment - just 4 choices (threadsafe/not-thread safe and 32 or 64 bit) not on a Unix/Linux system where there are other additional factors. And then there's this upgrade issue. When PHP is upgraded all these random modules have to upgraded, too. That's why there are package managers or the windows Installer bundling some PECL stuff (or MSFT's Web Installer thingy) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta wrote: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? This depends on what distribution you are using in Linux ... SUSE11.4 I have a nice array of new extensions which I can just download with package manager which will do any SUSE specific magic, such as checking for other files that need to be loaded with the extension. On windows this is not quite so easy, but is essentially the same process. We have been adding private builds of extensions that were not being included in the windows builds simply by downloading a copy from another location. As long as the file is built compatible with your PHP version that is all that is needed to add or update a single extension. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta wrote: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them That one is PEAR http://pear.php.net/ -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Sun, Jun 5, 2011 at 01:00, Andi Gutmans a...@zend.com wrote: In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. People have been afraid of suggesting new exts to core due to the policy of moving stuff from core to pecl, rather then vice verca, which has failed miserably. The only people who don't like our *bang* you have all you may possibly want approach are the python lovers. Gearman and memcache(d) are definitely something we should be bundling too. ZMQ is also imo a good candidate. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
How about the Yaml extension?, it looks well maintained enough: http://pecl.php.net/package/yaml Regards, David On Sun, Jun 5, 2011 at 2:33 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jun 5, 2011 at 01:00, Andi Gutmans a...@zend.com wrote: In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. People have been afraid of suggesting new exts to core due to the policy of moving stuff from core to pecl, rather then vice verca, which has failed miserably. The only people who don't like our *bang* you have all you may possibly want approach are the python lovers. Gearman and memcache(d) are definitely something we should be bundling too. ZMQ is also imo a good candidate. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
hi, On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! Being in core is not a sign of good maintenance. There are so many poorly maintained part in core as well. Also some exts are simply not used anymore or do not have active developers, nothing we can do will change that. If you use some of them, then try to contribute and take the hand over them (you being anyone reading this mail, not you alone:). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 05.06.2011 13:40, schrieb Pierre Joye: hi, On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! Being in core is not a sign of good maintenance. There are so many poorly maintained part in core as well. but they are running through some autotests a fucking PECL extension which is not updated for years and where bugreports are ignored is out of reach even for only smallest fixes Also some exts are simply not used anymore or do not have active developers but they compile with recent versions and if not the build will stop and someone fix it If you use some of them, then try to contribute and take the hand over them (you being anyone reading this mail, not you alone:) sorry, as php-user i can not take my hand over i can only realize that devleop anything depending on PECL is a dangerous game if it is not one time payed throw away-code and will end on the road to hell for big and over years maintained projects normally every maintainer which will not rebuild his package for every php-release and fix compile warnings from time to time should be burned down (including php-users not using E_ALL | E_STRICT on developemnt machines and fix warnings/notices) signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On Sun, Jun 5, 2011 at 1:00 AM, Andi Gutmans a...@zend.com wrote: For starters I would bundle ext/mongo which is very well maintained; see if we can get thrift_protocol contributed to PECL and included (support HBase and Cassdandra and used by a few PHP SDKs integrating with these data stores). I see two problems with this specific extension. One is that apache.org uses CLA, we do not allow CLA, even in PECL. Or is this project does not follow this rule? The 2nd one is that the implementation is rather not very nice.C++ usage for the sake of using C++, use c0x/c90 types instead of safely detect types or using std headers (stdint, inttypes, etc.), could have been done easily using php's stream (slightly slower but almost irrelevant in this case). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 06/05/2011 08:50 AM, Reindl Harald wrote: Also some exts are simply not used anymore or do not have active developers but they compile with recent versions and if not the build will stop and someone fix it Sorry, but that doesn't actually happen. Only commonly used core things are regularly tested. We have plenty of core SAPIs, for example, that haven't been compiled in years and likely don't work at all. The same goes for pecl. Commonly used pecl extensions tend to work well, but the fringe stuff, like gdchart, which I wrote, by the way, gets very little attention. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
hi, On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald h.rei...@thelounge.net wrote: Being in core is not a sign of good maintenance. There are so many poorly maintained part in core as well. but they are running through some autotests a fucking PECL extension which is not updated for years and where bugreports are ignored is out of reach even for only smallest fixes Again, please change your tone. Thanks. This comment brings nothing to the discussion and only states again what Richard says, so my comment will be the same as well. Also some exts are simply not used anymore or do not have active developers but they compile with recent versions and if not the build will stop and someone fix it Report bugs work pretty well, I do fix unmaintained extension very often. If you use some of them, then try to contribute and take the hand over them (you being anyone reading this mail, not you alone:) sorry, as php-user i can not take my hand over You can write tests, for core or pecl, there is no difference, no excuse not to contribute. i can only realize that devleop anything depending on PECL is a dangerous game if it is not one time payed throw away-code and will end on the road to hell for big and over years maintained projects Again, same for core. There is zero guarantee than some extension will be maintained in the long run, I repeat: Absolutely no guarantee. Only continuous work and contributions make an extension rock and well maintained. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Am 05.06.2011 13:58, schrieb Rasmus: On 06/05/2011 08:50 AM, Reindl Harald wrote: Also some exts are simply not used anymore or do not have active developers but they compile with recent 3versions and if not the build will stop and someone fix it Sorry, but that doesn't actually happen. Only commonly used core things are regularly tested. why not? We have plenty of core SAPIs, for example, that haven't been compiled in years and likely don't work at all. sounds terrible until now i thought it compiles it works is the worst attitude but i do not know if it compiles is even worser The same goes for pecl. Commonly used pecl extensions tend to work well so where can the user see if it is commonly used? but the fringe stuff like gdchart, which I wrote, by the way, gets very little attention so why there is no notice that it is no longer maintained so that possible users see this before it stops to work like gdchart did for php 5.3 Release 0.2.0: PHP Version: PHP version 6.0.0 or older what a bull***t if it not works for 5.3 since a long time so make a fat deprecated warning or even remove it because it does not work and is a risk for every one who installs it bugfixing would be really glad, but if noone cares remove died code and do not suggest will work even with php6 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jun 5, 2011 at 12:57, Pierre Joye pierre@gmail.com wrote: However, for technologies specific extension, be hyped or not, I see no reason to bundle them. It makes no sense to bundle mongodb, memcached clients or whatever other specific features. I can't think of a statement I would disagree more with. These are exactly the ones we should be bundling. My reasoning is simple. The key for bundling extensions is to have them available for most hosting solutions. If a shared host provides No. Join the real world again. Anything not in vanilla PHP is hard to install because it causes more work in maintenance of the server, and increases the risk of fuckups etc etc Being able to use hyped technology out-of-the box is exactly what we want to achieve. -Hannes just for the record, I agree with Pierre on this one. our userbase has two distinct group: those who are using shared hosting and usually use some third party cms or write their own crappy suboptimal code, and those who use php to build bleeding edge custom product (either on top of some 3rd party framework, or on their own). for the first group, they doesn't configure their installation, but their hosting providers do that for them. those providers usually has custom configuration or compilation of php, because by default, there are many ways where one user in the shared environment can blow up or compromise the full server. so for those people, including more stuff in the core means change, which they have to adapt, and migrate (add more disable_ to the vhost configs or recompile php without the newly included stuff). btw. usually the general cms solutions targets the standard installations, so they won't use stuff like mongodb. at least not as a requirement in their core functionalities. the other group, now they usually use and need such stuff, but they are willing and able to install the necessary extensions. btw. my biggest problem with bleeding edge technologies like redis, mongodb or memcache(and they aren't that new or bleeding edge...) is not the fact that they aren't in the core, but that we lack good php extensions to interact with them. for example we have two concurent lib for memcached, both have their cons and pros, for redis afaik the best implementation and actively maintened lib is rediska, we don't have anything for redis in pear/pecl, for mongodb at least we ?have? a feature complete implementation. so I think that providing/improving those would be a better idea than including what we currently have for marketing purposes. Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 05.06.2011 13:40, schrieb Pierre Joye: hi, On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! Being in core is not a sign of good maintenance. There are so many poorly maintained part in core as well. but they are running through some autotests a fucking PECL extension which is not updated for years and where bugreports are ignored is out of reach even for only smallest fixes Also some exts are simply not used anymore or do not have active developers but they compile with recent versions and if not the build will stop and someone fix it If you use some of them, then try to contribute and take the hand over them (you being anyone reading this mail, not you alone:) sorry, as php-user i can not take my hand over i can only realize that devleop anything depending on PECL is a dangerous game if it is not one time payed throw away-code and will end on the road to hell for big and over years maintained projects normally every maintainer which will not rebuild his package for every php-release and fix compile warnings from time to time should be burned down (including php-users not using E_ALL | E_STRICT on developemnt machines and fix warnings/notices) you both forgot that there was and will be cases when an extension gets moved from core to pecl. either because it's not maintained anymore, or got obsolete. so that gambling is still there. and if the core problem is that we don't have enough capacity/manpower to maintain at least the important extension, than I'm not sure that this could be solved with moving them to core. Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Sat, 2011-06-04 at 23:00 +, Andi Gutmans wrote: Hi, I've been getting quite a few inquiries re: PHP's lack of support for modern technologies such as NoSQL databases (for lack of better term). There is some (mistaken) perception that PHP is behind on this front. I'm in the believe that PHP should bundle rather less than more and we should advertise PECL better and probably better separate Siberia from well maintained parts. For average users I see not too much benefit by bundling. Distributors often make no difference between PECL and Core extensions in their repositories and on some distributions one even can't find all Core extensions while PECL stuff is there. I found lots of PECL stuff on shared hosts, also. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 06/05/2011 09:06 AM, Reindl Harald wrote: Am 05.06.2011 13:58, schrieb Rasmus: On 06/05/2011 08:50 AM, Reindl Harald wrote: Also some exts are simply not used anymore or do not have active developers but they compile with recent 3versions and if not the build will stop and someone fix it Sorry, but that doesn't actually happen. Only commonly used core things are regularly tested. why not? Simply because they depend on 3rd-party things that most of the core devs simply don't use. I have never installed and tested pi3web, Roxen and tried to use PHP as a milter extension, for example. Have you? These are all core sapi modules in PHP 5.3, but they can't be tested in isolation. Just like you need MySQL installed and configured correctly to run the MySQL tests. But MySQL is common and popular, so this is tested all the time. Once again, most developers work on what they need, myself included. We share what we work on, but we don't work on demand on things other people need. If you need something that isn't well-supported or isn't getting much attention, it is your own responsibility to either figure out how to maintain it yourself or find someone you can pay to do it for you. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
(Andi - I sent this before going out this morning - but I can't see it on the list this evening ... ) Andi Gutmans wrote: I think one of the problems is that in the past we always ensured that the extensions for key current technologies were bundled with PHP i.e. mysql, json soap/xml. This was one of our biggest strengths and advantages and it would propagate to Linux distros, shared hosting, etc.. Therefore, I think we should move towards bundling some of the key extensions to ensure they are easily found by people esp. when people are getting them via third parties. I think people are missing one of the MAIN things here! How many Linux distributions provide PHP as a single package? NOTHING needs to be bundled with PHP with the modern methods of package management. We just need to fully document and support adding new packages to the distributed network of what is available. My SUSE 11.4 package list gives a number of perfectly stable third party packages as well as the 'main stream' extensions. It WOULD be nice to restore the parallel system for Windows with the same configuration of matching packages? What also works nicely for me is the distributed .ini structure that SUSE introduced. Rather than the vast list of extra package data in php.ini, it is simply stripped out to the relevant package.ini file. Switching packages on and off is just a matter of adding .off to the end of the .ini file name and straight away I can see what I've disabled to test something out. I would then suggest that some of the things that are currently bundled could also be stripped out to allow finer control. Mysqlnd is a case in point. Why should I have to build my own copy of PHP just to remove that when there is no difference in it being made a shared package? Why do I need APC when I'm happily using eaccelerator ... and so on ... -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching around. Thanks Olivier (iPhone) Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit : Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
done http://pecl.php.net/bugs/bug.php?id=2274 BTW: that PHP 5.3.5 is the highest version in the dropdown for bugreports does not provide the feeling of maintaining Am 05.06.2011 20:39, schrieb Olivier Hill: Could you open a bug for GeoIP? Being aware of bugs helps more than bitching around. Thanks Olivier (iPhone) Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit : Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
Hello everyone, The following categorizes bundled/enabled/core, and lists extensions as they stand today (compiled via snaps). I don't exactly know what this means, but writing this feels appropriate: - Bundled : An extension that is bundled * ./configure --enable-ext (or --with-ext) is available but required * Not sure how best to compile this list, separated by --enable/--with - Bundled-enabled : Same as bundled, but enabled by default * ./configure alone includes it * 5.3: Core,ctype,date,dom,ereg,fileinfo,filter,hash,iconv,json,libxml, pcre,PDO,pdo_sqlite,Phar,posix,Reflection,session,SimpleXML,SPL, SQLite,sqlite3,standard,tokenizer,xml,xmlreader,xmlwriter * 5.4: Same as 5.3 except 'SQLite' was removed * External requirements: libxml2, Others? - Bundled-core : An extension that cannot be disabled * ./configure --disable-all does not exclude it * 5.3: Core,date,ereg,pcre,reflection,SPL,standard * 5.4: Same as 5.3 * External requirements: Others? Of course this does not apply to Linux distributions, but we don't [directly] control that. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Can't bundle geoip with the database due to the license on it. Would make it a pretty useless extension to have in that case. S On 5 Jun 2011, at 11:39, Olivier Hill olivier.h...@gmail.com wrote: Could you open a bug for GeoIP? Being aware of bugs helps more than bitching around. Thanks Olivier (iPhone) Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit : Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! -- 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] Bundling modern extensions
there is no need to bundle GeoIP or the databae GeoIP is part of the os-deployment and the database have to be updated every month with a script, the problem here was only that nobody cared about the extension over years Am 06.06.2011 00:21, schrieb Scott MacVicar: Can't bundle geoip with the database due to the license on it. Would make it a pretty useless extension to have in that case. S On 5 Jun 2011, at 11:39, Olivier Hill olivier.h...@gmail.com wrote: Could you open a bug for GeoIP? Being aware of bugs helps more than bitching around. Thanks Olivier (iPhone) Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit : Am 05.06.2011 12:57, schrieb Pierre Joye: The last point is that pecl allows a much more flexible release management than the core will even do. in theory So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint DO NOT USE IT until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if geoip_db_get_all_info is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really! signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Bundling modern extensions
On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. - S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Enable pecl_http by default (or, always), and bundle APC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 6/4/2011 8:55 PM, Philip Olson wrote: In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Enable pecl_http by default (or, always), and bundle APC. Regards, Philip APC, +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 06/04/2011 09:03 PM, Scott MacVicar wrote: On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. And OAuth2 is simple enough that an extension really isn't needed for it. OAuth1 was painful and the extension helped a lot. But all the painful bits that the extension takes care of are gone in OAuth2. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Jun 4, 2011, at 6:00 PM, Rasmus wrote: On 06/04/2011 09:03 PM, Scott MacVicar wrote: On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. And OAuth2 is simple enough that an extension really isn't needed for it. OAuth1 was painful and the extension helped a lot. But all the painful bits that the extension takes care of are gone in OAuth2. Ideas for how and where to document PHP+OAuth2? Like, should we keep ext/oauth documented as is but expand it to include plenty of OAuth2 information? That may be confusing... hmmm Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Hi, APC +1 I don't think it should have OAuth2 bundled (and I don't consider OAuth v1 too). Related to thrift, I'm more in favor of having a native Cassandra implementation than bundling thrift on PHP. Thrift's implementation is not good (sorry Scott) and the overhead of bootstrapping, connecting and running commands is very slow. I think that before it becomes bundled it should be revisited and optimized. Cheers, On Sat, Jun 4, 2011 at 10:00 PM, Rasmus ras...@lerdorf.com wrote: On 06/04/2011 09:03 PM, Scott MacVicar wrote: On Jun 4, 2011, at 4:57 PM, Stas Malyshev wrote: Hi! In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. Maybe also oauth? It's getting popular and widely used. OAuth is basically outdated now, OAuth2 is going through the final IETF certification steps. No real technical changes in the last few drafts. And OAuth2 is simple enough that an extension really isn't needed for it. OAuth1 was painful and the extension helped a lot. But all the painful bits that the extension takes care of are gone in OAuth2. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Hi All, In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. With regards to the http extension, I've been using it in production for a while, but ran into an issue where it segfaulted and killed the worker when parsing incomplete headers (as returned by some servers) bug 19390 [1]. While this has been resolved in a more recent release, the thought of things segfaulting makes me nervous. Are there additional hoops for pecl extensions to jump through to 'prove' their stability before making it into the core? thanks paul [1] http://pecl.php.net/bugs/bug.php?id=19390 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
