# Bundling "modern" extensions - Thread: https://externals.io/message/52898 - Original archive: https://news-web.php.net/php.internals/52898 - Started by Andi Gutmans on 2011-06-04T23:00:28+00:00 - Messages: 69 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/52898.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #52898 — Andi Gutmans — 2011-06-04T23:00:28+00:00 URL: https://externals.io/message/52898#52898 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 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. 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). 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. Anyway, I am not suggesting we go and include a lot more but I think there are a few key ones, and I would start with very strong NoSQL support extensions that already exist to ensure the eco-system picks them up and we make them readily available + get rid of any false perceptions that exist. Andi --- ## #52899 — Stas Malyshev — 2011-06-04T23:57:28+00:00 URL: https://externals.io/message/52898#52899 · In reply to: #52898 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #52900 — Scott MacVicar — 2011-06-05T00:03:02+00:00 URL: https://externals.io/message/52898#52900 · In reply to: #52899 > Hi! > > > […] > > 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 --- ## #52902 — Philip Olson — 2011-06-05T00:55:24+00:00 URL: https://externals.io/message/52898#52902 · In reply to: #52898 > 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 --- ## #52903 — Marcel Esser — 2011-06-05T00:56:49+00:00 URL: https://externals.io/message/52898#52903 · In reply to: #52902 > > […] > Enable pecl_http by default (or, always), and bundle APC. > > Regards, > Philip APC, +1 --- ## #52904 — Rasmus — 2011-06-05T01:00:01+00:00 URL: https://externals.io/message/52898#52904 · In reply to: #52900 > > > > […] > > 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 --- ## #52905 — Philip Olson — 2011-06-05T01:09:50+00:00 URL: https://externals.io/message/52898#52905 · In reply to: #52904 > > > […] > > 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 --- ## #52906 — guilhermeblanco@gmail.com — 2011-06-05T01:13:56+00:00 URL: https://externals.io/message/52898#52906 · In reply to: #52904 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, > > > […] > > 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 > > -- > > > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com São Paulo - SP/Brazil --- ## #52910 — Paul Reinheimer — 2011-06-05T01:58:26+00:00 URL: https://externals.io/message/52898#52910 · In reply to: #52898 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 --- ## #52911 — Hannes Magnusson — 2011-06-05T07:33:00+00:00 URL: https://externals.io/message/52898#52911 · In reply to: #52898 > > 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 --- ## #52912 — dukeofgaming — 2011-06-05T07:57:01+00:00 URL: https://externals.io/message/52898#52912 · In reply to: #52911 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 wrote: > > > […] > 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 --- ## #52915 — Pierre Joye — 2011-06-05T10:57:55+00:00 URL: https://externals.io/message/52898#52915 · In reply to: #52898 hi, 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. For general purposes extensions or really globally useful (as any almost all php users will have a use), like pecl's http, I'm all for having them in the core. In the case of http it was even already proposed and somehow rejected. If Mike feels like it is time again to propose it, then let him do it. oAuth2 or yaml may be bundled but I'm not a fan of getting those in tbh. 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. 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. It will be also hardly possible to begin to bundle all nosql/cache extensions in the core without creating a maintenance nightmare. I don't want to imagine the QA checks for the core if we begin to have them in core. No, I really don't want. The last point is that pecl allows a much more flexible release management than the core will even do. So instead of doing some marketing/communication actions by bundling some known extensions, we should better promote pecl better. Improve the website (ping me if you like to help) by supporting non svn repository like github&co, etc. etc. Cheers, > 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 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. > > 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). > > 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. > > Anyway, I am not suggesting we go and include a lot more but I think there are a few key ones, and I would start with very strong NoSQL support extensions that already exist to ensure the eco-system picks them up and we make them readily available + get rid of any false perceptions that exist. > > Andi > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52916 — Hannes Magnusson — 2011-06-05T11:09:13+00:00 URL: https://externals.io/message/52898#52916 · In reply to: #52915 > 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 --- ## #52917 — Pierre Joye — 2011-06-05T11:17:05+00:00 URL: https://externals.io/message/52898#52917 · In reply to: #52916 On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson wrote: > I can't think of a statement I would disagree more with. These are > exactly the ones we should be bundling. > > […] > > > 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. > Being able to use "hyped technology" out-of-the box is exactly what we > want to achieve. I use mongodb, couchdb, memcached, and many other out of the box. My only concerns is the lack of pecl support for many of them and that's why I do think it is the way to go. And that's what the distros want as well. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52919 — Reindl Harald — 2011-06-05T11:37:36+00:00 URL: https://externals.io/message/52898#52919 · In reply to: #52915 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! --- ## #52920 — Pierre Joye — 2011-06-05T11:40:02+00:00 URL: https://externals.io/message/52898#52920 · In reply to: #52919 hi, > Am 05.06.2011 12:57, schrieb Pierre Joye: > > > […] > > in theory > > > […] > > 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 --- ## #52921 — Pierre Joye — 2011-06-05T11:41:00+00:00 URL: https://externals.io/message/52898#52921 · In reply to: #52919 > Am 05.06.2011 12:57, schrieb Pierre Joye: > > > […] > > in theory No, that's a fact. You can do releases whenever you want, at your own wish. Whether developers do it or not is something different but it is the root of pecl. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #52922 — Reindl Harald — 2011-06-05T11:50:28+00:00 URL: https://externals.io/message/52898#52922 · In reply to: #52920 Am 05.06.2011 13:40, schrieb Pierre Joye: > hi, > > > > […] > > 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) --- ## #52923 — Pierre Joye — 2011-06-05T11:56:06+00:00 URL: https://externals.io/message/52898#52923 · In reply to: #52898 > 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 --- ## #52924 — Rasmus — 2011-06-05T11:58:27+00:00 URL: https://externals.io/message/52898#52924 · In reply to: #52922 > > […] > > 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 --- ## #52926 — Pierre Joye — 2011-06-05T12:00:13+00:00 URL: https://externals.io/message/52898#52926 · In reply to: #52922 hi, > > […] > > 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. > > […] > > 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. > > […] > > 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 --- ## #52928 — Reindl Harald — 2011-06-05T12:06:39+00:00 URL: https://externals.io/message/52898#52928 · In reply to: #52924 Am 05.06.2011 13:58, schrieb Rasmus: > > > […] > > 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" --- ## #52931 — Ferenc Kovacs — 2011-06-05T12:54:20+00:00 URL: https://externals.io/message/52898#52931 · In reply to: #52916 On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson wrote: > > > […] > > I can't think of a statement I would disagree more with. These are > exactly the ones we should be bundling. > > > > […] > > > 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 --- ## #52932 — Ferenc Kovacs — 2011-06-05T13:03:58+00:00 URL: https://externals.io/message/52898#52932 · In reply to: #52922 On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald wrote: > > > Am 05.06.2011 13:40, schrieb Pierre Joye: > > […] > wrote: > > […] > some > > […] > > 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 > > > […] > > but they compile with recent versions and if not > the build will stop and someone fix it > > > […] > > 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 --- ## #52934 — johannes@schlueters.de — 2011-06-05T14:02:06+00:00 URL: https://externals.io/message/52898#52934 · In reply to: #52898 > 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 --- Next page: https://externals.io/message/52898.md?page=2