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
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
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
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
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
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,
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
--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
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
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
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
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
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.magnusson@gmail.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
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
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
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson
hannes.magnusson@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 providesNo. 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
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson
hannes.magnusson@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 providesNo. 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 etcCan 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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
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
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson <hannes.magnusson@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 providesNo. 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 etcBeing 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
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
On Mon, Jun 6, 2011 at 5:18 PM, Larry Garfield larry@garfieldtech.comwrote:
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
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
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
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 nosql&co 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
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!
hi,
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
Am 05.06.2011 13:40, schrieb Pierre Joye:
hi,
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)
Also some exts are simply not used anymore or do not have active
developersbut 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
Am 05.06.2011 13:58, schrieb Rasmus:
Also some exts are simply not used anymore or do not have active
developersbut they compile with recent 3versions and if not
the build will stop and someone fix itSorry, 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"
Am 05.06.2011 13:58, schrieb Rasmus:
Also some exts are simply not used anymore or do not have active
developersbut they compile with recent 3versions and if not
the build will stop and someone fix itSorry, 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
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
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
developersbut 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
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 05.06.2011 13:40, schrieb Pierre Joye:
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.reindl@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 fixesAlso some exts are simply not used anymore or do not have active
developersbut they compile with recent versions and if not
the build will stop and someone fix itIf 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 projectsnormally 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 usingE_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
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
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
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.reindl@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 ithttp://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-extensionhttp://pecl.php.net/package/ssh2
was three years not maintained and could not compiled
with recent versions of libssh2 without some magic
patches from distributorshttp://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!
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.reindl@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 ithttp://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-extensionhttp://pecl.php.net/package/ssh2
was three years not maintained and could not compiled
with recent versions of libssh2 without some magic
patches from distributorshttp://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/
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
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.reindl@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 ithttp://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-extensionhttp://pecl.php.net/package/ssh2
was three years not maintained and could not compiled
with recent versions of libssh2 without some magic
patches from distributorshttp://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!
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
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.reindl@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 ithttp://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-extensionhttp://pecl.php.net/package/ssh2
was three years not maintained and could not compiled
with recent versions of libssh2 without some magic
patches from distributorshttp://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!
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
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
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,
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
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
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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
weierophinney@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.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Martin Scotta
On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
weierophinney@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
On Mon, Jun 6, 2011 at 11:40 PM, Martin Scotta martinscotta@gmail.comwrote:
Martin Scotta
On Mon, Jun 6, 2011 at 6:53 PM, Matthew Weier O'Phinney
weierophinney@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
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
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
2011/6/7 Johannes Schlüter johannes@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
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?
Martin Scotta
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.reindl@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
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
Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.reindl@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....?
Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.reindl@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
Am 07.06.2011 11:32, schrieb David Muir:
Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.reindl@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
Am 07.06.2011 11:32, schrieb David Muir:
Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.reindl@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 thatI 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
Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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
What exactly are the security issues?
I'm really trying to figure out where you're coming from
look in the php-changelogs how often "open_base_dir" was bypassed
in the past and think about a low-level API for writing extensions
installed by a user - after that think about how many idiots out
there driving servers into a security-hell only with PHP and what
the impact will be give them a low-level API
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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
Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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 userexcept if dl is enabled of course.
i think nobody out there will enable this and hope such
crazy things are not enabled by default!
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.reindl@thelounge.netwrote:
Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald <h.reindl@thelounge.net
wrote:Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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 userexcept 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=psy&hl=hu&source=hp&q=intitle:phpinfo()+enable_dl&aq=f&aqi=&aql=&oq=&pbx=1&bav=on.2,or.r_gc.r_pw.&fp=580ca0074daf5780&biw=1280&bih=939
Tyrael
Martin Scotta
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald <h.reindl@thelounge.net
wrote:
Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald <h.reindl@thelounge.net
wrote:Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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 userexcept 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:
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
On Tue, Jun 7, 2011 at 4:59 PM, Martin Scotta martinscotta@gmail.comwrote:
Martin Scotta
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald <h.reindl@thelounge.net
wrote:
Am 07.06.2011 15:08, schrieb Ferenc Kovacs:
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald <h.reindl@thelounge.net
wrote:Am 07.06.2011 14:44, schrieb David Muir:
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 reasonsSo 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 userexcept 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:
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
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
Martin Scotta
Am 07.06.2011 04:42, schrieb Martin Scotta:
On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald <h.reindl@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_interfaceEither 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
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
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.
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
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
(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
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
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