Hello internals,
i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have
security relevant changes and no new features whatsoever.
For the biggest changes i'd like to see the following:
- Adding PECL/Phar as default extension
- Add open_filename debug info to streams
- Add object handler get_debug_info
- Split
E_STRICTintoE_STRICTandE_DEPRECATED
a more complete list can be seen here:
http://oss.backendmedia.com/PhP53
Besides 1) all mentioned action points require an API change. The first
point could also be done in 5.2.3.
As soon as we start with 5.3 development we also need to find a way how
to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff
only happens in 5.2 and eventually gets MFB'ed. An idea is to provide
an easy way to send commits to bugs.php.net and have them as new category
"merge required". Maybe we can have the commit script create a link for
this.
comments welcome
- but please think before writing
& only write if you have something to say
Best regards,
Marcus
Hello Marcus,
Adding a new branch is a huge pita for people distributing binary
extension, including our own Windows build and PECL4WIN sites. So
perhaps we should wait with adding a new branch since 5.2 is a really
nice release, the php5 that works very well :)
I think that adding a Phar to the distribution for 5.2.3 is an excellent
idea. I also see no reason to stop adding smaller non-api-breaking
features to 5.2.x and wait until we have a more compelling reason (more
goodies than those listed in points 2-4) to branch out.
Edin
Marcus Boerger wrote:
Hello internals,
i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have
security relevant changes and no new features whatsoever.For the biggest changes i'd like to see the following:
- Adding PECL/Phar as default extension
- Add open_filename debug info to streams
- Add object handler get_debug_info
- Split
E_STRICTintoE_STRICTandE_DEPRECATEDa more complete list can be seen here:
http://oss.backendmedia.com/PhP53Besides 1) all mentioned action points require an API change. The first
point could also be done in 5.2.3.As soon as we start with 5.3 development we also need to find a way how
to keep track of unmerged changes in 5.2/5.3. Right now a lot of stuff
only happens in 5.2 and eventually gets MFB'ed. An idea is to provide
an easy way to send commits to bugs.php.net and have them as new category
"merge required". Maybe we can have the commit script create a link for
this.comments welcome
- but please think before writing
& only write if you have something to sayBest regards,
Marcus
Hello internals,
i'd like to start 5.3 development from 5.2.2 and have 5.2.* only have
security relevant changes and no new features whatsoever.
I'd like to wait for the end of the year (i.e. for the end of PHP4 support period) and then branch off 5_3.
We can use this time to make 5_2 as stable as we can and "test" all the new features in HEAD (*).
I believe there are a lot of things to do/fix in 5_2 and we should not leave it unattended in favor of 5_3.
(*) Yes, I mean everybody should start using HEAD as a development branch and forget that "bah, that Unicode crap again!" attitude.
--
Wbr,
Antony Dovgal
Hello internals,
i'd like to start 5.3 development from 5.2.2 and have 5.2.* only
have
security relevant changes and no new features whatsoever.For the biggest changes i'd like to see the following:
- Adding PECL/Phar as default extension
I really don't think we need phar in core, certainly not enabled by
default. If someone can make a good case for including it, I'd love
to hear it.
- Add open_filename debug info to streams
What would this mean for performance and memory usage of file ops?
- Add object handler get_debug_info
- Split
E_STRICTintoE_STRICTandE_DEPRECATED
Seems like a good idea. +1
So far I don't really see a key reason to move to 5.3, this is a
significant change requiring us to maintain an additional branch at
least for a few months. This is not a decision we should make
lightly, for non-essential reasons. IMHO.
Ilia Alshanetsky
Hello Ilia,
Friday, May 4, 2007, 6:54:33 PM, you wrote:
Hello internals,
i'd like to start 5.3 development from 5.2.2 and have 5.2.* only
have
security relevant changes and no new features whatsoever.For the biggest changes i'd like to see the following:
- Adding PECL/Phar as default extension
I really don't think we need phar in core, certainly not enabled by
default. If someone can make a good case for including it, I'd love
to hear it.
Easier distributing/deployment of stuff and phar even allows to use the
packed files as is from within the package or unpacked without any
change. We use phar already for pear. Having the extension version that
allows the mentioned untouched unpacking feature would help a lot of
people.
- Add open_filename debug info to streams
What would this mean for performance and memory usage of file ops?
An additional malloc and strcpy on opening and an additional free
on closing. We could however limit actual use to --enable-debug builds.
- Add object handler get_debug_info
- Split
E_STRICTintoE_STRICTandE_DEPRECATED
Seems like a good idea. +1
So far I don't really see a key reason to move to 5.3, this is a
significant change requiring us to maintain an additional branch at
least for a few months. This is not a decision we should make
lightly, for non-essential reasons. IMHO.
Ilia Alshanetsky
Best regards,
Marcus
I really don't think we need phar in core, certainly not enabled by
default. If someone can make a good case for including it, I'd love
to hear it.Easier distributing/deployment of stuff and phar even allows to use the
packed files as is from within the package or unpacked without any
change. We use phar already for pear. Having the extension version that
allows the mentioned untouched unpacking feature would help a lot of
people.
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than 10 seconds using pecl install phar.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds usingpecl install phar.
PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main
distro will open up a whole new way to distribute PHP applications which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.
Edin
Edink,
Just like we build snapshots we can create source packages with pre-
built configure scripts for the individual PECL extensions. In fact
that's something we need to look into anyway.
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more
than
10 seconds usingpecl install phar.PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main
distro will open up a whole new way to distribute PHP applications
which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.Edin
Ilia Alshanetsky
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds usingpecl install phar.PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.).
autoconf-2.13 is not required, it's only recommended.
Also the same build system is required to build PHP, so this argument looks bogus to me.
Having Phar in the main
distro will open up a whole new way to distribute PHP applications which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds usingpecl install phar.PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.).autoconf-2.13 is not required, it's only recommended.
Also the same build system is required to build PHP, so this argument
looks bogus to me.
PHP source tarballs come with configure scripts pre-built so auto tools
(and very old one at that) are not needed. They are for the pecl installs.
I really don't understand the objection. We have added the extensions to
the core before when we want to promote a certain technology.
Edin
Antony Dovgal wrote:
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds usingpecl install phar.PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.).autoconf-2.13 is not required, it's only recommended.
Also the same build system is required to build PHP, so this argument
looks bogus to me.PHP source tarballs come with configure scripts pre-built so auto tools
(and very old one at that) are not needed. They are for the pecl installs.
You need only autoconf and it's really easy to install.
I really don't understand the objection. We have added the extensions to
the core before when we want to promote a certain technology.
I object because I believe extensions should be moved from core to PECL, not the other way round.
If you don't like PECL or think it's too difficult to use, let's make it easy enough for all.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
[snip]
I really don't understand the objection. We have added the extensions to
the core before when we want to promote a certain technology.I object because I believe extensions should be moved from core to PECL,
not the other way round.
If you don't like PECL or think it's too difficult to use, let's make it
easy enough for all.
Its a noble goal, but lets be realistic. Having and extension in the
core package is always going to be easier than installing it as an
external package. There is also how wide spread usage of something we
want to get. I think that Phar is going to be useful only if its
universally available in the PHP installs, and I think that would a good
thing for PHP.
Edin
Antony Dovgal wrote:
[snip]I really don't understand the objection. We have added the extensions to
the core before when we want to promote a certain technology.I object because I believe extensions should be moved from core to PECL,
not the other way round.
If you don't like PECL or think it's too difficult to use, let's make it
easy enough for all.Its a noble goal, but lets be realistic. Having and extension in the
core package is always going to be easier than installing it as an
external package.
Both ways are easy enough for me.
Moreover, I think adding an extension using PECL is much more easier than recompiling&reinstalling PHP.
There is also how wide spread usage of something we
want to get.
I think that Phar is going to be useful only if its
universally available in the PHP installs, and I think that would a good
thing for PHP.
This is valid for any other PECL module.
Most of the extensions we have are useful and good things.
--
Wbr,
Antony Dovgal
Am Freitag, 4. Mai 2007 20:16 schrieb Edin Kadribasic:
I think that Phar is going to be useful only if its
universally available in the PHP installs, and I think that would a good
thing for PHP.
Edin, why do you bind the usefulness to the number of installs? That sounds
more like enthusiam than an elaborated argument.:)
Best Regards,
Oliver
If you don't like PECL or think it's too difficult to use, let's make
it easy enough for all.
How easy is it for an average user on a shared host that needs X, to
use pecl to get X, without an intervention by the webhost?
I know y'all don't have this issue; But a few zillion PHP developers do.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
If you don't like PECL or think it's too difficult to use, let's make
it easy enough for all.How easy is it for an average user on a shared host that needs X, to
use pecl to get X, without an intervention by the webhost?
It's the same for those who don't have root privileges - you can't add an extension without
a help from your sysadmin and it does not depend whether the extension is in core or in PECL.
--
Wbr,
Antony Dovgal
Hello Richard,
exactly the point. Most developers here can easily compile PHP on their
own and typically never face a situation where that is no option or not
possible at all. Believe it or not. Stuff in PECL is not being used. Not
by the majority of PHP users that rely on prebuild/preinstalled stuff.
best regards
marcus
Friday, May 4, 2007, 9:22:40 PM, you wrote:
If you don't like PECL or think it's too difficult to use, let's make
it easy enough for all.
How easy is it for an average user on a shared host that needs X, to
use pecl to get X, without an intervention by the webhost?
I know y'all don't have this issue; But a few zillion PHP developers do.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Best regards,
Marcus
Am Freitag, 4. Mai 2007 20:09 schrieb Antony Dovgal:
not the other way round. If you don't like PECL or think it's too difficult
to use, let's make it easy enough for all.
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be a
major facilitation. php will then automatically download and intergrate the
extension source into the source tree before 'make' will compile everything.
With user interaction, of course! - But maybe that's enthusiasm too.
Regards,
Oliver
Hello Oliver,
we are discussing situations where make is no option here. Everone that
hasmake as an option and all tools available can always easily do:
pecl install <extension>
Without the pear or pecl commandyou can also simply download the pecl
extension package and do the following:
tar -x <package>
phpize
./configure
make
make install
Also still easy enough.
However this is in many situation not possible at all. For once it is
impossible if you are using a shared server.
best regards
masrcus
Thursday, May 10, 2007, 10:29:08 PM, you wrote:
Am Freitag, 4. Mai 2007 20:09 schrieb Antony Dovgal:
not the other way round. If you don't like PECL or think it's too difficult
to use, let's make it easy enough for all.
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be a
major facilitation. php will then automatically download and intergrate the
extension source into the source tree before 'make' will compile everything.
With user interaction, of course! - But maybe that's enthusiasm too.
Regards,
Oliver
Best regards,
Marcus
Am Donnerstag, 10. Mai 2007 22:47 schrieb Marcus Boerger:
we are discussing situations where make is no option here.
However this is in many situation not possible at all. For once it is
impossible if you are using a shared server.
I know, If I follow that part of the discussion, it's about .php files (apps)
not pecl, right.
Regards,
Oliver
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be a
Maybe in more generic form like --enable-pecl=EXTENSION or
--enable-pecl=/path/to/file.tgz but if autoconf magicians among us could
pull this off it might be nice shortcut. Automatic downloading can be
tricky, but the rest should be relatively easy...
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
That is good point. If PECL extensions could be integrated into php by just
set --enable-extensionX while compiling the php distribution. That would be aMaybe in more generic form like --enable-pecl=EXTENSION or
--enable-pecl=/path/to/file.tgz but if autoconf magicians among us could
pull this off it might be nice shortcut. Automatic downloading can be
tricky, but the rest should be relatively easy...
Yeah I was also thinking about something like
--enable-pecl-extensionName
example:
./configure --enable-pecl-phar --enable-pecl-geoip ...
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/--
David
Edin Kadribasic wrote:
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds usingpecl install phar.PECL is great, but it does require a build system with increasingly
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main
distro will open up a whole new way to distribute PHP applications which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99% of
the systems. Thats the only way that phar has a good chance of really
taking off as a php code distribution approach.
I personally think that it really improves the distribution process a
lot to make this widely available. So I would say yes, add it to core,
just like we added ext/json because we feel that this is technology
people should be able to rely on.
regards,
Lukas
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99%
of the systems. Thats the only way that phar has a good chance of
really taking off as a php code distribution approach.
It sounds like the merits of having phar is would only be apparent
after it is included in the core and everyone starts using it because
of that. This won't happen simply because most software producers
can't rely on extensions that are only available in version X.
Ilia Alshanetsky
Hello Ilia,
Friday, May 4, 2007, 9:24:08 PM, you wrote:
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99%
of the systems. Thats the only way that phar has a good chance of
really taking off as a php code distribution approach.
It sounds like the merits of having phar is would only be apparent
after it is included in the core and everyone starts using it because
of that. This won't happen simply because most software producers
can't rely on extensions that are only available in version X.
So we stop developing PHP 6 immediately, right?
Ah no it is the reason people like you don't MFB.
Best regards,
Marcus
Ilia Alshanetsky wrote:
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99% of
the systems. Thats the only way that phar has a good chance of really
taking off as a php code distribution approach.It sounds like the merits of having phar is would only be apparent after
it is included in the core and everyone starts using it because of that.
This won't happen simply because most software producers can't rely on
extensions that are only available in version X.
No, the point is that if we want to push something, we need to add it
sooner rather than later, because there will be a delay anyways. Also
simply by putting it into core, we make sure that phar gets into the
long terms plans of users (which are then more likely to accept the
transition pain, because they know its going to be around and maintained).
regards,
Lukas
Ilia Alshanetsky wrote:
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99% of the
systems. Thats the only way that phar has a good chance of really taking
off as a php code distribution approach.It sounds like the merits of having phar is would only be apparent after it
is included in the core and everyone starts using it because of that. This
won't happen simply because most software producers can't rely on extensions
that are only available in version X.No, the point is that if we want to push something, we need to add it sooner
rather than later, because there will be a delay anyways. Also simply by
putting it into core, we make sure that phar gets into the long terms plans of
users (which are then more likely to accept the transition pain, because they
know its going to be around and maintained).
Right, so the question is whether we want to push it or not. What would
be good reasons for adding phar to the core?
regards,
Derick
Am Freitag, 4. Mai 2007 21:24 schrieb Ilia Alshanetsky:
It sounds like the merits of having phar is would only be apparent
after it is included in the core and everyone starts using it because
of that. This won't happen simply because most software producers
can't rely on extensions that are only available in version X.
I don't understand the last senctence, to be true. But I have another good
reason which will hinder that:
"Phars support compression using gzip if the zlib extension is present, and
using bzip2 if the bz2 extension is present."
As far as I know that are two different compression formats!? So you need to
handle three types of archives. Are you going to provide three versions of
every archive?
Regards,
Oliver
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main
distro will open up a whole new way to distribute PHP applications which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.
I'm personally not sure phar is that great way of distributing apps -
it's yet another format not supported by standard tools and I don't
really see much of an advantage to using it versus just making a package
with any of the existing package formats and I see a number of
disadvantages - non-standard format, hard to work with packed scripts
with available filesystem tools, etc. But that's my opinion and I fully
expect some people to hold exactly the opposite opinion. The question is
however is phar so important that everybody needs it in the main source?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
expect some people to hold exactly the opposite opinion. The question is
however is phar so important that everybody needs it in the main source?
Yup, that is indeed the question. Like I said I think it is important
enough.
regards,
Lukas
Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly have that tool
- you can run phar archives out of the box - untouched
- you can extract phar archives and run them - still untouched
- you can provide phar archives that do not require a phar extension
To your question "is phar so important that everybody needs it in the
main source." I think the above means it should.
best regards
marcus
Friday, May 4, 2007, 9:36:22 PM, you wrote:
obsolete set of tools (autoconf-2.13, etc.). Having Phar in the main
distro will open up a whole new way to distribute PHP applications which
would be a great advantage. The current system of distributing a bunch
of PHP files has some shortcomings.
I'm personally not sure phar is that great way of distributing apps -
it's yet another format not supported by standard tools and I don't
really see much of an advantage to using it versus just making a package
with any of the existing package formats and I see a number of
disadvantages - non-standard format, hard to work with packed scripts
with available filesystem tools, etc. But that's my opinion and I fully
expect some people to hold exactly the opposite opinion. The question is
however is phar so important that everybody needs it in the main source?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Best regards,
Marcus
I think phar is a nice idea but honestly haven't had enough bandwidth to
check it out in more detail. Has there been some thorough analysis on
the performance impact of it and whether this is the optimal recommended
way for our users to distribute apps? The idea is actually very
interesting but we should be pretty certain we're doing the right thing
before we distribute it. We can spend some time looking at it in more
detail.
Btw, it seems to me that because of the way Apache works for most of our
users it actually won't be that useful and just act like a .tar archieve
which needs to be extracted. This is unless the user implements some
kind of front controller. It would really be nice if we have the 99%
common Apache application use-case figured out and docuemnted before we
put our PHP dev team weight behind it. Or am I completely missing some
magic here?
Re: debug info for files. I wouldn't like to see that in non-debug runs.
It could be optional at runtime if you want.
Andi
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, May 04, 2007 12:44 PM
To: Stas Malyshev
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly
have that tool- you can run phar archives out of the box - untouched
- you can extract phar archives and run them - still untouched
- you can provide phar archives that do not require a phar extension
To your question "is phar so important that everybody needs
it in the main source." I think the above means it should.best regards
marcusFriday, May 4, 2007, 9:36:22 PM, you wrote:
obsolete set of tools (autoconf-2.13, etc.). Having Phar
in the main
distro will open up a whole new way to distribute PHP applications
which would be a great advantage. The current system of
distributing
a bunch of PHP files has some shortcomings.I'm personally not sure phar is that great way of
distributing apps -
it's yet another format not supported by standard tools and I don't
really see much of an advantage to using it versus just making a
package with any of the existing package formats and I see
a number of
disadvantages - non-standard format, hard to work with
packed scripts
with available filesystem tools, etc. But that's my opinion and I
fully expect some people to hold exactly the opposite opinion. The
question is however is phar so important that everybody
needs it in the main source?Stanislav Malyshev, Zend Products Engineer stas@zend.com
http://www.zend.com/Best regards,
Marcus--
To
unsubscribe, visit: http://www.php.net/unsub.php
Hello Andi,
Friday, May 4, 2007, 9:55:23 PM, you wrote:
I think phar is a nice idea but honestly haven't had enough bandwidth to
check it out in more detail. Has there been some thorough analysis on
the performance impact of it and whether this is the optimal recommended
way for our users to distribute apps? The idea is actually very
interesting but we should be pretty certain we're doing the right thing
before we distribute it. We can spend some time looking at it in more
detail.
You guys spent a good effort in such analysis in the past. Would be very
nice to hear something in that direction from you.
Btw, it seems to me that because of the way Apache works for most of our
users it actually won't be that useful and just act like a .tar archieve
which needs to be extracted. This is unless the user implements some
kind of front controller. It would really be nice if we have the 99%
common Apache application use-case figured out and docuemnted before we
put our PHP dev team weight behind it. Or am I completely missing some
magic here?
not at all. It perfectly works for includes. But i have no idea how to use
it from a url directly...well you can provide some tricks. But i wouldn't
recommend those.
Andi
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, May 04, 2007 12:44 PM
To: Stas Malyshev
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly
have that tool- you can run phar archives out of the box - untouched
- you can extract phar archives and run them - still untouched
- you can provide phar archives that do not require a phar extension
To your question "is phar so important that everybody needs
it in the main source." I think the above means it should.best regards
marcusFriday, May 4, 2007, 9:36:22 PM, you wrote:
obsolete set of tools (autoconf-2.13, etc.). Having Phar
in the main
distro will open up a whole new way to distribute PHP applications
which would be a great advantage. The current system of
distributing
a bunch of PHP files has some shortcomings.I'm personally not sure phar is that great way of
distributing apps -
it's yet another format not supported by standard tools and I don't
really see much of an advantage to using it versus just making a
package with any of the existing package formats and I see
a number of
disadvantages - non-standard format, hard to work with
packed scripts
with available filesystem tools, etc. But that's my opinion and I
fully expect some people to hold exactly the opposite opinion. The
question is however is phar so important that everybody
needs it in the main source?Stanislav Malyshev, Zend Products Engineer stas@zend.com
http://www.zend.com/Best regards,
Marcus--
To
unsubscribe, visit: http://www.php.net/unsub.php
Best regards,
Marcus
Don't think we every looked at it in detail. Or maybe I just don't
remember.
I think the URL thing is one of the biggest question marks. It will not
be very useful for our users if they can't deploy the one big phar
(similar to Java EE WAR or EAR).
It can probably be done with some kind of front controller trick and
mod_rewrite. It's something worth checking out but it might cause a big
performance hit for our users.
Andi
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, May 04, 2007 1:06 PM
To: Andi Gutmans
Cc: Stas Malyshev; Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3Hello Andi,
Friday, May 4, 2007, 9:55:23 PM, you wrote:
I think phar is a nice idea but honestly haven't had enough
bandwidth
to check it out in more detail. Has there been some
thorough analysis
on the performance impact of it and whether this is the optimal
recommended way for our users to distribute apps? The idea
is actually
very interesting but we should be pretty certain we're
doing the right
thing before we distribute it. We can spend some time
looking at it in
more detail.You guys spent a good effort in such analysis in the past.
Would be very nice to hear something in that direction from you.Btw, it seems to me that because of the way Apache works
for most of
our users it actually won't be that useful and just act like a .tar
archieve which needs to be extracted. This is unless the user
implements some kind of front controller. It would really
be nice if
we have the 99% common Apache application use-case figured out and
docuemnted before we put our PHP dev team weight behind it. Or am I
completely missing some magic here?not at all. It perfectly works for includes. But i have no
idea how to use it from a url directly...well you can provide
some tricks. But i wouldn't recommend those.Andi
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, May 04, 2007 12:44 PM
To: Stas Malyshev
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly
have that
tool- you can run phar archives out of the box - untouched
- you can extract phar archives and run them - still untouched
- you can provide phar archives that do not require a phar
extensionTo your question "is phar so important that everybody
needs it in the
main source." I think the above means it should.best regards
marcusFriday, May 4, 2007, 9:36:22 PM, you wrote:
obsolete set of tools (autoconf-2.13, etc.). Having Phar
in the main
distro will open up a whole new way to distribute PHP
applications
which would be a great advantage. The current system of
distributing
a bunch of PHP files has some shortcomings.I'm personally not sure phar is that great way of
distributing apps -
it's yet another format not supported by standard tools
and I don't
really see much of an advantage to using it versus just making a
package with any of the existing package formats and I see
a number of
disadvantages - non-standard format, hard to work with
packed scripts
with available filesystem tools, etc. But that's my
opinion and I
fully expect some people to hold exactly the opposite
opinion. The
question is however is phar so important that everybody
needs it in the main source?Stanislav Malyshev, Zend Products Engineer stas@zend.com
http://www.zend.com/Best regards,
Marcus--
To
unsubscribe,
visit: http://www.php.net/unsub.phpBest regards,
Marcus
When I first wrote PHP_Archive the entire point of the stub script was
to handle incoming requests, just like the multitude of applications
that have everything go through "index.php" (S9Y for an example).
Using Phar with MultiViews and mod_rewrite is just same as funnelling
everything through a single regular PHP script, this was one of the
design goals and is a very common practice.
The main difference here, is with web applications you have non-HTML
resources you must also handle - this WILL incur a performance hit over
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the typical usage is not to serve a large number of
users, this is usually not an issue.
These techniques work just fine.
- Davey
Marcus Boerger wrote:
Hello Andi,
Friday, May 4, 2007, 9:55:23 PM, you wrote:
I think phar is a nice idea but honestly haven't had enough bandwidth to
check it out in more detail. Has there been some thorough analysis on
the performance impact of it and whether this is the optimal recommended
way for our users to distribute apps? The idea is actually very
interesting but we should be pretty certain we're doing the right thing
before we distribute it. We can spend some time looking at it in more
detail.You guys spent a good effort in such analysis in the past. Would be very
nice to hear something in that direction from you.Btw, it seems to me that because of the way Apache works for most of our
users it actually won't be that useful and just act like a .tar archieve
which needs to be extracted. This is unless the user implements some
kind of front controller. It would really be nice if we have the 99%
common Apache application use-case figured out and docuemnted before we
put our PHP dev team weight behind it. Or am I completely missing some
magic here?not at all. It perfectly works for includes. But i have no idea how to use
it from a url directly...well you can provide some tricks. But i wouldn't
recommend those.Andi
-----Original Message-----
From: Marcus Boerger [mailto:helly@php.net]
Sent: Friday, May 04, 2007 12:44 PM
To: Stas Malyshev
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3Hello Stanislav,
- you don't need a tool - well php - but hey you probbaly
have that tool- you can run phar archives out of the box - untouched
- you can extract phar archives and run them - still untouched
- you can provide phar archives that do not require a phar extension
To your question "is phar so important that everybody needs
it in the main source." I think the above means it should.best regards
marcusFriday, May 4, 2007, 9:36:22 PM, you wrote:
obsolete set of tools (autoconf-2.13, etc.). Having Phar
in the main
distro will open up a whole new way to distribute PHP applications
which would be a great advantage. The current system of
distributing
a bunch of PHP files has some shortcomings.
I'm personally not sure phar is that great way of
distributing apps -
it's yet another format not supported by standard tools and I don't
really see much of an advantage to using it versus just making a
package with any of the existing package formats and I see
a number of
disadvantages - non-standard format, hard to work with
packed scripts
with available filesystem tools, etc. But that's my opinion and I
fully expect some people to hold exactly the opposite opinion. The
question is however is phar so important that everybody
needs it in the main source?
--
Stanislav Malyshev, Zend Products Engineer stas@zend.com
http://www.zend.com/Best regards,
Marcus--
To
unsubscribe, visit: http://www.php.net/unsub.phpBest regards,
Marcus
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the typical usage is not to serve a large number of
users, this is usually not an issue.
In other words, it is not meant to deploy production applications, only
local-user applications. Then the question raises again - why exactly we
need the module? Low-traffic occasional-use apps do not need top
performance, and PHP module should be just enough for them.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the typical usage is not to serve a large number of
users, this is usually not an issue.In other words, it is not meant to deploy production applications, only
local-user applications. Then the question raises again - why exactly we
need the module? Low-traffic occasional-use apps do not need top
performance, and PHP module should be just enough for them.
They need bearable performance, which can be a bit lower than "normal"
applications. I am not sure what the state is in the relation to
bytecode caches and phar, but AFAIK they cannot be leveraged yet. So
there you have your performance penalty :)
regards,
Lukas
Stanislav Malyshev wrote:
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the typical usage is not to serve a large number of
users, this is usually not an issue.In other words, it is not meant to deploy production applications, only
local-user applications. Then the question raises again - why exactly we
need the module? Low-traffic occasional-use apps do not need top
performance, and PHP module should be just enough for them.
No, not "in other words". I said the words I said, because I meant those
words. I'm talking about small production deployments. I don't see
php.net or yahoo! using phar any time soon, but any site not currently
leveraging a bytecode cache would certainly be included. This is the
MAJORITY of PHP deployment.
Something akin in traffic and use as bugs.php.net could use phar without
any detriment (though not knowing what else that particular machine is
used for, I wouldn't say to move bugs.php.net itself over, just giving
an idea of size and scale :)
- Davey
No, not "in other words". I said the words I said, because I meant those
words. I'm talking about small production deployments. I don't see
Why small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
No, not "in other words". I said the words I said, because I meant
those words. I'm talking about small production deployments. I don't
seeWhy small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.
Because sometimes you like to not waste resources unnecessarily? Maybe
because their host only allows default PHP config and doesn't provide
PEAR or PECL?
- Davey
Stanislav Malyshev wrote:
No, not "in other words". I said the words I said, because I meant
those words. I'm talking about small production deployments. I don't
seeWhy small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.Because sometimes you like to not waste resources unnecessarily? Maybe
because their host only allows default PHP config and doesn't provide
PEAR or PECL?
Given that either PHP_Archive or pecl/phar are not required to execute
a phar, I really don't see the point here.
Now, from a "performence" point of view, how faster (or less slow) is
the extension in comparison to the user land stream implementation?
--Pierre
Hello Pierre,
Tuesday, May 8, 2007, 10:59:08 PM, you wrote:
Stanislav Malyshev wrote:
No, not "in other words". I said the words I said, because I meant
those words. I'm talking about small production deployments. I don't
seeWhy small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.Because sometimes you like to not waste resources unnecessarily? Maybe
because their host only allows default PHP config and doesn't provide
PEAR or PECL?
Given that either PHP_Archive or pecl/phar are not required to execute
a phar, I really don't see the point here.
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
a situation where practically every phar would have to include the
PHP_Archive.Which would be suboptimal.
Best regards,
Marcus
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
Yes, the whole whopping 20K of space uncompressed and with comments, so
could be probably 10K or less without comments, whitespace and minimized
for extraction. Serious waste of bandwidth worth discussing.
a situation where practically every phar would have to include the
PHP_Archive.Which would be suboptimal.
That would be suboptimal if we suppose everybody uses phar archives.
Since it is not the case and most apps would neither run in phars nor
require to be run from phars without extraction, optimizing PHP for use
in these use cases in not necessary.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead toYes, the whole whopping 20K of space uncompressed and with comments, so
could be probably 10K or less without comments, whitespace and minimized
for extraction. Serious waste of bandwidth worth discussing.
Yeah, I do not think that the size is really that big of an issue in
this case. It would just be a code management inconvenience (having to
update the same thing in all your applications, which requires
downloading an new version of the application in its entirety etc.).
@Greg: Do you have any benchmark result ready to compare the difference
in start up cost?
regards,
Lukas
Hello Pierre,
Tuesday, May 8, 2007, 10:59:08 PM, you wrote:
Stanislav Malyshev wrote:
No, not "in other words". I said the words I said, because I meant
those words. I'm talking about small production deployments. I don't
seeWhy small deployment can't use PHP phar then? If they don't use bytecode
cache parsing PHP on each request obviously isn't a problem for them.Because sometimes you like to not waste resources unnecessarily? Maybe
because their host only allows default PHP config and doesn't provide
PEAR or PECL?Given that either PHP_Archive or pecl/phar are not required to execute
a phar, I really don't see the point here.There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
a situation where practically every phar would have to include the
PHP_Archive.Which would be suboptimal.
Well, as I can understand your point, it is not really a problem.
pear.phar is bundled and used by hundred of users and developers to
install pear and it includes the php code.
That does not answer my question, what's the gain of using an
extension instead of the php implementation (to execute it)? (please
don't answer me to try it myself :)
--Pierre
- you don't need a tool - well php - but hey you probbaly have that tool
Yes, but they can't open it by any other standard system tool. I.e. you
always need PHP - and of specific version - to work with this file. And
I don't know how you expect all kinds of proven and widely used tools
like mod_rewrite, .htaccess, etc. to work with phar-ed application.
- you can run phar archives out of the box - untouched
You can't however see files there, edit files, copy files, etc. by any
of the thousands of tools made by people to work with files.
- you can extract phar archives and run them - still untouched
To extract them, you again can use one and only one tool, which might
not be available on the system you want to open the archive on. That's
all consequences of inventing yet another separate packaging format on
top of dozens already in existence. Java at least used existing format...
- you can provide phar archives that do not require a phar extension
What do you mean, how? And if you can - why don't you always do so? Why
do you need phar extension at all?
To your question "is phar so important that everybody needs it in the
main source." I think the above means it should.
Sorry, not clear to me how exactly it means so. There are a lot of
extensions that live in PECL and do all kinds of interesting things -
why phar is so special?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Btw, I think if phar is a good way of deploying self-contained apps like
WAR and EAR then we should think of including this in the default
distro. It definitely has value. I just don't think we're quite there
yet.
Andi
-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: Friday, May 04, 2007 1:07 PM
To: Marcus Boerger
Cc: Edin Kadribasic; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
- you don't need a tool - well php - but hey you probbaly have that
toolYes, but they can't open it by any other standard system
tool. I.e. you always need PHP - and of specific version - to
work with this file. And I don't know how you expect all
kinds of proven and widely used tools like mod_rewrite,
.htaccess, etc. to work with phar-ed application.
- you can run phar archives out of the box - untouched
You can't however see files there, edit files, copy files,
etc. by any of the thousands of tools made by people to work
with files.
- you can extract phar archives and run them - still untouched
To extract them, you again can use one and only one tool,
which might not be available on the system you want to open
the archive on. That's all consequences of inventing yet
another separate packaging format on top of dozens already in
existence. Java at least used existing format...
- you can provide phar archives that do not require a phar extension
What do you mean, how? And if you can - why don't you always
do so? Why do you need phar extension at all?To your question "is phar so important that everybody needs
it in the
main source." I think the above means it should.Sorry, not clear to me how exactly it means so. There are a
lot of extensions that live in PECL and do all kinds of
interesting things - why phar is so special?Stanislav Malyshev, Zend Products Engineer stas@zend.com
http://www.zend.com/--
To
unsubscribe, visit: http://www.php.net/unsub.php
Btw, I think if phar is a good way of deploying self-contained apps like
WAR and EAR then we should think of including this in the default
distro. It definitely has value. I just don't think we're quite there
yet.
WAR/EAR isn't really self-contained - they are managed by the app
server. So far we don't have similar system in PHP. And as I pointed out
all Java *ARs are essentially zip's with some additional files inside
and specific file structure. I like it better than inventing another
file format.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
Friday, May 4, 2007, 10:07:13 PM, you wrote:
- you don't need a tool - well php - but hey you probbaly have that tool
Yes, but they can't open it by any other standard system tool. I.e. you
always need PHP - and of specific version -
nope, there ispear/phar - perfectly compatible and runs on any version
to work with this file. And
I don't know how you expect all kinds of proven and widely used tools
like mod_rewrite, .htaccess, etc. to work with phar-ed application.
they most likely don't, it is designed for deployment and for running
includes directly.
- you can run phar archives out of the box - untouched
You can't however see files there, edit files, copy files, etc. by any
of the thousands of tools made by people to work with files.
If need be, i'll write a windows-commander plugin :-)
- you can extract phar archives and run them - still untouched
To extract them, you again can use one and only one tool, which might
not be available on the system you want to open the archive on. That's
all consequences of inventing yet another separate packaging format on
top of dozens already in existence. Java at least used existing format...
pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no option
- you can provide phar archives that do not require a phar extension
What do you mean, how? And if you can - why don't you always do so? Why
do you need phar extension at all?
slow? bigger? overhead?
To your question "is phar so important that everybody needs it in the
main source." I think the above means it should.
Sorry, not clear to me how exactly it means so. There are a lot of
extensions that live in PECL and do all kinds of interesting things -
why phar is so special?
Interesting and not maintained for the most. Sometimes working on one or
the other very specific php version only. And often even without
documentation.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Best regards,
Marcus
Hello Stanislav,
Friday, May 4, 2007, 10:07:13 PM, you wrote:
- you don't need a tool - well php - but hey you probbaly have that tool
Yes, but they can't open it by any other standard system tool. I.e. you
always need PHP - and of specific version -nope, there ispear/phar - perfectly compatible and runs on any version
to work with this file. And
I don't know how you expect all kinds of proven and widely used tools
like mod_rewrite, .htaccess, etc. to work with phar-ed application.they most likely don't, it is designed for deployment and for running
includes directly.
- you can run phar archives out of the box - untouched
You can't however see files there, edit files, copy files, etc. by any
of the thousands of tools made by people to work with files.If need be, i'll write a windows-commander plugin :-)
Just to address your issue Stanislav, I have spoken with Marcus and
I'm starting to write a little application with php-gtk to handle all
type of operations with Phar's as such as:
- Viewing the files in a phar
- Adding files to a phar
- Deleting files from a phar
- Viewing the files themselves in a phar
- you can extract phar archives and run them - still untouched
To extract them, you again can use one and only one tool, which might
not be available on the system you want to open the archive on. That's
all consequences of inventing yet another separate packaging format on
top of dozens already in existence. Java at least used existing format...pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no option
- you can provide phar archives that do not require a phar extension
What do you mean, how? And if you can - why don't you always do so? Why
do you need phar extension at all?slow? bigger? overhead?
To your question "is phar so important that everybody needs it in the
main source." I think the above means it should.Sorry, not clear to me how exactly it means so. There are a lot of
extensions that live in PECL and do all kinds of interesting things -
why phar is so special?Interesting and not maintained for the most. Sometimes working on one or
the other very specific php version only. And often even without
documentation.--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/Best regards,
Marcus--
regards,
David
they most likely don't, it is designed for deployment and for running
includes directly.
What do you mean "directly"? Do you mean this is designed for running
application only specifically crafted to run inside phar and would break
some or most of the existing applications not designed specifically for
it? Then even less reason to recommend it as a way to deploy real
applications.
If need be, i'll write a windows-commander plugin :-)
Will you also write plugins for all thousand other tools people use or
only for those two you personally use? ;) Note that for all other
formats the tools are out there today. You can open zip or tgz on
almost any system in existence, and almost any file manager you could
find understands these formats or natively or with tons of readily
available plugins.
pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no option
And what is "pear install"? I don't have such command in my Windows by
default. Neither I have it on my Linux. I would have to install PEAR for
that, right? Even only to know what's inside.
slow? bigger? overhead?
Meaning, of no practical use nobody would package their real-world apps
this way. Then I guess it's not really an option?
Interesting and not maintained for the most. Sometimes working on one or
the other very specific php version only. And often even without
documentation.
This is as I see for very specific applications too, and the manual says
there's no currently stable version of phar.
My opinion is that it is not right to recommend it as preferred way to
deploy PHP applications. I know there are many people that it suits
their needs - but those people as I understand have to keep in mind they
work for phar anyway, so they might as well install one more extension.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi,
pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no optionAnd what is "pear install"? I don't have such command in my Windows by
default. Neither I have it on my Linux. I would have to install PEAR for
that, right? Even only to know what's inside.
A little note about executing a phar file, no phar extension is
required to execute a phar archive, neither to create it (see
http://pear.php.net/package/PHP_Archive) . We distribute pear.phar
since a couple of stable releases already. It is easier/faster to
create it using pecl/phar. I'm sure there is a big difference
(performence) when a phar is executed with or without pecl/phar, it is
slow anyway.
I see this extension as a packager tool only (where end users are
packages user).
NB: Recent changes in the extensions may be available only in the
extension, I did not follow its recent developments.
--Pierre
A little note about executing a phar file, no phar extension is
required to execute a phar archive, neither to create it (see
Right, but php and PEAR are required to read/create/inspect the archive.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi,
A little note about executing a phar file, no phar extension is
required to execute a phar archive, neither to create it (seeRight, but php and PEAR are required to read/create/inspect the archive.
Who has inspected pear.phar? Not a lot I think, but we all installed
pear using at least once (without ext/phar).
Not pear directly but PHP_Archive or the pecl/phar. However phar is
good to test something in a non intrusive way (no file to install, you
can do "php foo.phar" or run it in a webserver if you rename it to
.php) or as a self contained installer. But I would not recommend to
ever use a phar for other purposes like in a production environment.
--Pierre
.php) or as a self contained installer. But I would not recommend to
ever use a phar for other purposes like in a production environment.
That's the question - if phar is not to be recommended in production as
deployment format, it belongs to PECL.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
Monday, May 7, 2007, 7:07:09 AM, you wrote:
they most likely don't, it is designed for deployment and for running
includes directly.
What do you mean "directly"? Do you mean this is designed for running
application only specifically crafted to run inside phar and would break
some or most of the existing applications not designed specifically for
it? Then even less reason to recommend it as a way to deploy real
applications.
It means you can run a phar file. How is that so hard to understand.
See the docs: http://php.net/phar
pear install phar - or - pecl install phar - done
oh wait the point is that pecl install doesn't work or is in 99% no option
And what is "pear install"? I don't have such command in my Windows by
default. Neither I have it on my Linux. I would have to install PEAR for
that, right? Even only to know what's inside.
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would be
very nice here.
slow? bigger? overhead?
Meaning, of no practical use nobody would package their real-world apps
this way. Then I guess it's not really an option?
As said you can try stuff in a phar and then extract it. And lemme think,
a war or jar or whatever crap doesn't make java faster either. But hey it
would be a nice trick to turn PHP evenmore into Java so you should promote
it.
Interesting and not maintained for the most. Sometimes working on one or
the other very specific php version only. And often even without
documentation.
This is as I see for very specific applications too, and the manual says
there's no currently stable version of phar.
Strange, pecl lists three stable versions since end of march:
http://pecl.php.net/package/phar
And phar has been stable since end of last year. We only decided to not
mark it stable to be able to rename a few things.
My opinion
I see
is that it is not right to recommend it as preferred way to
deploy PHP applications. I know there are many people that it suits
their needs - but those people as I understand have to keep in mind they
work for phar anyway, so they might as well install one more extension.
Once again, that is in most cases no option at all.
Best regards,
Marcus
It means you can run a phar file. How is that so hard to understand.
It is not hard to understand. What seems to be hard to understand is
that the scenario you describe is by no way the only scenario PHP files
run in. Not all applications are single entry point and of those that
are, not all applications are suitable to work in non-filesystem
environment. Thus using phar in applications not specifically designed
for it and in environments which presume files are in filesystem might
prove harder than some think.
a war or jar or whatever crap doesn't make java faster either. But hey it
would be a nice trick to turn PHP evenmore into Java so you should promote
it.
If it was meant as some kind of a jab I'm afraid it was lost on me, I
don't understand how it is relevant to anything, sorry. :)
Strange, pecl lists three stable versions since end of march:
http://pecl.php.net/package/phar
I guess you should fix the manual then :)
Once again, that is in most cases no option at all.
How it's no option in most cases? And while we are at it, what is the
"most cases" anyway? Is that most PHP deployments including millions of
hosting clones all alike or most people supposed to use packaged
applications (as opposed to writing own PHP scripts) or most people
running complex production environments (as opposed to just playing with
some private site) or most of what?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
It means you can run a phar file. How is that so hard to understand.
It is not hard to understand. What seems to be hard to understand is
that the scenario you describe is by no way the only scenario PHP files
run in. Not all applications are single entry point and of those that
are, not all applications are suitable to work in non-filesystem
environment. Thus using phar in applications not specifically designed
for it and in environments which presume files are in filesystem might
prove harder than some think.
So if you are wondering about use cases, the PEAR installer is a good
example. Generally I would say phar lends itself for self installing
applications, but also for applications you run infrequently, that are
not that performance critical (which does not mean you want them to run
extra slow either) and where you want minimal fuss in keeping an
uptodate version.
I do not see phar's be used as the runtime after installation for most
applications of course. But a sizeable number of them could be run this way.
Also it is one of those cases of "build it and they will come". So once
we put this into core, people will take notice, tools will be developed,
others will be adapted to become compatible etc.
Maybe we should for a moment shift the discussion from "if its useful"
(because several half way smart people have said it is), to "is it
technically sensibly implemented". Just give these guys the benefit of
the doubt on the usefulness part and make sure its good on the
implementation part.
regards,
Lukas
regards,
Lukas
So if you are wondering about use cases, the PEAR installer is a good
example. Generally I would say phar lends itself for self installing
Let's separate phar as installer format and phar as runtime format. Only
problem I have with the former is that it's custom NIH-syndrome-enabled
format which no tools except PEAR can work with. I don't have any
problem with the idea of having distribution format inside PHP toolkit
or the intent of the project, on the contrary - I think it's a great
think that should be taken even further - probably up to something like
InstallShield.php ;)
As for phar in runtime I think moving away from filesystem would create
more problems than solve. Of course, there are people that think the
opposite.
Also it is one of those cases of "build it and they will come". So once
we put this into core, people will take notice, tools will be developed,
others will be adapted to become compatible etc.
We don't need phar extension in the core to make phar installer, as far
as I understand.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hello Stanislav,
Monday, May 7, 2007, 8:50:18 PM, you wrote:
So if you are wondering about use cases, the PEAR installer is a good
example. Generally I would say phar lends itself for self installing
Let's separate phar as installer format and phar as runtime format. Only
problem I have with the former is that it's custom NIH-syndrome-enabled
format which no tools except PEAR can work with. I don't have any
problem with the idea of having distribution format inside PHP toolkit
or the intent of the project, on the contrary - I think it's a great
think that should be taken even further - probably up to something like
InstallShield.php ;)
Phew, good.
As for phar in runtime I think moving away from filesystem would create
more problems than solve. Of course, there are people that think the
opposite.
Agreed. It may often bring a bunch of problems. However being able to
have some stuff kept in a package, like a database driver, is a good
thing. This is actually what is donewith most JARs. If we could do that
with the same format we use as a distribution format, then suddenly some
nice stuff is possibly. You use phar packaged fileto download some
packages that you only use as includes. Now you keep them in your web
space, disallow access to ".phar" and include the actualfiles via
"phar://...phar/...";. As a sideeffect you can easily check that the
package doesn't get changed. Now please note that from the beginning,
I did not say that this is something we should promote as the absolute
best thing. I am only saying that this is an option the pahr extension
offers.
Also it is one of those cases of "build it and they will come". So once
we put this into core, people will take notice, tools will be developed,
others will be adapted to become compatible etc.
We don't need phar extension in the core to make phar installer, as far
as I understand.
We will need it:
- by the time of PHP 6
- to be able to have PHARs without pretty big PHP_Archive stuff included
- "include phar://" run easily and always
And just to be certain, we are not trying to force anybody to use it.
Best regards,
Marcus
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting
it to PHP extensions but by fixing PHP 6 and enabling PEAR to work.
- to be able to have PHARs without pretty big PHP_Archive stuff included
It's for install, how big could it be? 20 K? If it's more, it can
probably be rewritten to be shorter :)
- "include phar://" run easily and always
I'm not sure we want include phar:// because include($file) and
include(realpath($file)) for example would work VERY different then.
Think about poor library writers having to deal with these things.
And just to be certain, we are not trying to force anybody to use it.
I thought this was officially declared non-argument in scope of PHP
discussions? ;)
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it to
PHP extensions but by fixing PHP 6 and enabling PEAR to work.
Let me agree with Greg here. We can not go back to the PHP 4.x way of
bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5
uses the phar, which works brilliantly. So the fix here is to make
something like phar work with PHP 6 as well. If it was to be based on
streams (which I think it can only be), then we need some way of
marking this new user stream as being local in order for require and
include to work on those. Making a hack in PHP to allow "phar://"
streams to work is a bad idea, a C-extension can easily work here.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it to
PHP extensions but by fixing PHP 6 and enabling PEAR to work.Let me agree with Greg here. We can not go back to the PHP 4.x way of
bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5
uses the phar, which works brilliantly. So the fix here is to make
something like phar work with PHP 6 as well. If it was to be based on
streams (which I think it can only be), then we need some way of
marking this new user stream as being local in order for require and
include to work on those. Making a hack in PHP to allow "phar://"
streams to work is a bad idea, a C-extension can easily work here.
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does not solve the
problem for anyone else but phar. If phar will be bundled or not does
not matter, this problem has to be solved anyway.
--Pierre
Hello internals,
Tuesday, May 8, 2007, 10:13:15 AM, Pierre wrote:
We will need it:
- by the time of PHP 6
I think this problem should be fixed not by killing PEAR and converting it to
PHP extensions but by fixing PHP 6 and enabling PEAR to work.Let me agree with Greg here. We can not go back to the PHP 4.x way of
bundling PEAR. It's a PITA for both the PEAR people and the RM. PHP 5
uses the phar, which works brilliantly. So the fix here is to make
something like phar work with PHP 6 as well. If it was to be based on
streams (which I think it can only be), then we need some way of
marking this new user stream as being local in order for require and
include to work on those. Making a hack in PHP to allow "phar://"
streams to work is a bad idea, a C-extension can easily work here.
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does not solve the
problem for anyone else but phar. If phar will be bundled or not does
not matter, this problem has to be solved anyway.
Right Pierre, as you said, this is a different thing that might have
to be addressed anyway. However phar is a real life thing that needs
to be working.
Besides, Phar is neither a custom extension - at least i do not see
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
Guys what I don't understand is why some few people bicker around
Phar so much, just because they have no private use for it? In the
past we have bundeled even stuff that has not been stable or in a
mature state.
And I have not seen a single reason against it. The only one close
so far was that PHARs cannot be handled with your favorite Winzip
or whatever you are using. Guess what, I have PHP installed and
last time I checked PHP worked nearly perfectly. And last time I had
to deal with JARs I did not have the slightest advantage of having
it be a ZIP file. Just because in all those Java formats you have to
provide specific files in a very specific format with very specific
content. And this is the absolute opposite of the flexibility we
aim for with Phar.
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem and b) we should
not eventhink of turning it into a JAR and hack around PHP all over.
Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on
the fly packing and Phar for deployment. And if some people want to
execute phars directly, then why the hell make it hard for them or
even disallow that?
Best regards,
Marcus
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem
And to read zip files (upload, ftp, remote data). I think each of us
has had to deal with zip data (read or write) more than once. It is a
mainstream need. Or if you mean that phar is not a mainstream problem
then I agree. But I don't really see the point to compare both, they
are too completely different extension (general purpose and
developer/packager extension).
I'm in general in favour of phar but I don't think we should start 5.3
for it. I don't think either that it is stable enough to be bundled. I
doubt it is possible to have a stable package in only three public
releases (even the first public release was already marked stable).
However once this package got a wider audience and users base, I don't
have real objections to do not bundle it even if I still think that
phar is a packager tool and have little to do with the mainstream
needs.
--Pierre
Hello Pierre,
Tuesday, May 8, 2007, 10:58:19 AM, you wrote:
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem
And to read zip files (upload, ftp, remote data). I think each of us
has had to deal with zip data (read or write) more than once. It is a
mainstream need. Or if you mean that phar is not a mainstream problem
then I agree. But I don't really see the point to compare both, they
are too completely different extension (general purpose and
developer/packager extension).
I hoped to make clear that even all of them are package extensions
at least to me they severe a different purpose. Especially I wanted
to point out that we should not make any of them executeable like
JARs.
I'm in general in favour of phar but I don't think we should start 5.3
for it. I don't think either that it is stable enough to be bundled. I
doubt it is possible to have a stable package in only three public
releases (even the first public release was already marked stable).
We do not need to create 5.3 to bundle it. And well if you design
something and test it thoroully you can mark even the first public
release as stable. We've even put phar to gcov.php.net prior to
releasing it to prevent memleaks and ensure a pretty high quality.
After that we waited ffor another half year and only then after
still being sure it works (by checking that it worked for us) we
released it.
However once this package got a wider audience and users base, I don't
have real objections to do not bundle it even if I still think that
phar is a packager tool and have little to do with the mainstream
needs.
In this case the audience is the PHP_Archive audience as well.
It is one of the things PECL was designed for. Develop something
in PHP and the turn it into a PHP extension.
--Pierre
Best regards,
Marcus
Pierre wrote:
I'm in general in favour of phar but I don't think we should start 5.3
for it. I don't think either that it is stable enough to be bundled. I
doubt it is possible to have a stable package in only three public
releases (even the first public release was already marked stable).
FYI, there were two beta releases prior to 1.0.0 stable, with months in
between the releases for testing, plus the test coverage at gcov is
quite good. Not that these are fantastic indicators of stability as we
all know but it is something :)
Greg
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does not solve the
problem for anyone else but phar. If phar will be bundled or not does
not matter, this problem has to be solved anyway.Right Pierre, as you said, this is a different thing that might have
to be addressed anyway. However phar is a real life thing that needs
to be working.Besides, Phar is neither a custom extension - at least i do not see
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
But the main argument for including it that it's going to solve the newly created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.
Guys what I don't understand is why some few people bicker around
Phar so much, just because they have no private use for it?
If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR.
I'm against including new PECL stuff in the core and I've repeated that several times already.
Things should go the other way round - from the core to PECL.
In the past we have bundeled even stuff that has not been stable or in a
mature state.
Well, THAT is a nice argument.
We've fucked it up in the past, let's do it again, huh?
And I have not seen a single reason against it.
I have not seen a single reason FOR it either.
The only half-valid reason is that phars will stop working in PHP6 because of the streams breakage.
But that's definitely the reason to fix streams, otherwise we'll have to include each & every extension using custom streams.
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem and b) we should
not eventhink of turning it into a JAR and hack around PHP all over.
Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on
the fly packing and Phar for deployment. And if some people want to
execute phars directly, then why the hell make it hard for them or
even disallow that?
--
Wbr,
Antony Dovgal
Hello Antony,
Tuesday, May 8, 2007, 10:59:28 AM, you wrote:
The point is to make local URL wrappers working, not only phar://.
Stanislav and Tony have a point, writing a custom extension to fix a
problem that we introduced is a bad idea and does not solve the
problem for anyone else but phar. If phar will be bundled or not does
not matter, this problem has to be solved anyway.Right Pierre, as you said, this is a different thing that might have
to be addressed anyway. However phar is a real life thing that needs
to be working.Besides, Phar is neither a custom extension - at least i do not see
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
But the main argument for including it that it's going to solve the newly created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.
It is not my main argument - not at all. My argument is that it is something
that serves a need perfectly and makes the PHP_Archive stuff turned into a
fast C extension. Including it would allow to make it a suggested sound and
save deployment solution with a bunch of nice additional pros.
Guys what I don't understand is why some few people bicker around
Phar so much, just because they have no private use for it?
If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR.
I'm against including new PECL stuff in the core and I've repeated that several times already.
Things should go the other way round - from the core to PECL.
We have no means at all to support that. And even after years of having PECL
I cannot see the slightest aim to solve the issue. All we have right now is
to provide stuff that works for experienced admins. Experienced in compiling
and automake tools. Before we can go in a all to PECL way of doing things we
would need to reduce the number of completely incompatible builds (ZTS,
debug, ZTS-debug, normal). Andwewould have to decide on a sane pugable API.
One that does not change from version to version. Not even additions would
be allowed. All would have to be done via callbacks. And eventually with
struct versioning. But we do not even allow a TODO discussion board on
php.net somewhere nor did we ever respect our own TODOs. So how is this ever
going to happen? So infact if we like something we can either bundle it or
have it die.
In the past we have bundeled even stuff that has not been stable or in a
mature state.
Well, THAT is a nice argument.
We've fucked it up in the past, let's do it again, huh?
Phar is stable. All I said is that we won't do the same mistake again.
Meaning that none of those arguemts speaks against Phar. If feel the
need to misinterpret these arguments than i am sorry.
Best regards,
Marcus
But the main argument for including it that it's going to solve the newly created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.It is not my main argument - not at all. My argument is that it is something
that serves a need perfectly and makes the PHP_Archive stuff turned into a
fast C extension. Including it would allow to make it a suggested sound and
save deployment solution with a bunch of nice additional pros.
Please correct me if I'm wrong: phars do work without PECL/phar, don't they?
Then why in hell do we need PECL/phar in the core? (except for that streams problem)
Because it's faster than PHP_Archive?
I don't really care if PEAR install takes 5 seconds or 4 seconds, I can wait one more second once in a month.
If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR.
I'm against including new PECL stuff in the core and I've repeated that several times already.
Things should go the other way round - from the core to PECL.We have no means at all to support that. And even after years of having PECL
I cannot see the slightest aim to solve the issue. All we have right now is
to provide stuff that works for experienced admins. Experienced in compiling
and automake tools.
The only tool required is autoconf (2.13 is recommended, other versions are supported too).
All the other tools are required by PHP itself. You don't need to be an experienced admin to
install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it..
(Btw, Ilia recently proposed to create packages with pre-built configure, so even the autoconf requirement would go).
Before we can go in a all to PECL way of doing things we
would need to reduce the number of completely incompatible builds (ZTS,
debug, ZTS-debug, normal).
I'm not sure I understand what you're talking about.
We never provided debug binary builds and I see no reasons to do it.
Andwewould have to decide on a sane pugable API.
Okay, let's do it.
We have a nice chance to break everything we can - it's PHP6 anyway =)
I'd really like to hear your thoughts on improving the API.
Want to make a separate thread?
One that does not change from version to version. Not even additions would
be allowed. All would have to be done via callbacks. And eventually with
struct versioning. But we do not even allow a TODO discussion board on
php.net somewhere nor did we ever respect our own TODOs.
This IS the discussion board.
So how is this ever going to happen?
So infact if we like something we can either bundle it or have it die.
Ok, so let me summarize it:
to leave PECL/phar in PECL you need a new pluggable API,
and to create the API you need a discussion board,
but even having it you would not discuss the API because nobody respects TODOs.
Did I miss something?
In the past we have bundeled even stuff that has not been stable or in a
mature state.Well, THAT is a nice argument.
We've fucked it up in the past, let's do it again, huh?Phar is stable. All I said is that we won't do the same mistake again.
PECL/json, PECL/zip and the others were/are stable too.
That doesn't mean there are no bugs we don't know of.
--
Wbr,
Antony Dovgal
Hello Antony,
it make it much harder as you would need to load PHP_Archive before
you can do anything else with them. It would mean you cannot easily
execute them unless they contain PHP_Archive themselves....
best regards
marcus
Tuesday, May 8, 2007, 11:39:32 AM, you wrote:
But the main argument for including it that it's going to solve the newly created problem.
I.e. PEAR and all the other phar packages work perfectly fine without it.It is not my main argument - not at all. My argument is that it is something
that serves a need perfectly and makes the PHP_Archive stuff turned into a
fast C extension. Including it would allow to make it a suggested sound and
save deployment solution with a bunch of nice additional pros.
Please correct me if I'm wrong: phars do work without PECL/phar, don't they?
Then why in hell do we need PECL/phar in the core? (except for that streams problem)
Because it's faster than PHP_Archive?
I don't really care if PEAR install takes 5 seconds or 4 seconds, I can
wait one more second once in a month.If you're talking about me, then you should know that I'm not against Phar/Greg/you or PEAR.
I'm against including new PECL stuff in the core and I've repeated that several times already.
Things should go the other way round - from the core to PECL.We have no means at all to support that. And even after years of having PECL
I cannot see the slightest aim to solve the issue. All we have right now is
to provide stuff that works for experienced admins. Experienced in compiling
and automake tools.
The only tool required is autoconf (2.13 is recommended, other versions are supported too).
All the other tools are required by PHP itself. You don't need to be an experienced admin to
install autoconf, this is typical anti-PECL FUD and I'm a bit tired to fight it..
(Btw, Ilia recently proposed to create packages with pre-built configure,
so even the autoconf requirement would go).
Before we can go in a all to PECL way of doing things we
would need to reduce the number of completely incompatible builds (ZTS,
debug, ZTS-debug, normal).
I'm not sure I understand what you're talking about.
We never provided debug binary builds and I see no reasons to do it.
Andwewould have to decide on a sane pugable API.
Okay, let's do it.
We have a nice chance to break everything we can - it's PHP6 anyway =)
I'd really like to hear your thoughts on improving the API.
Want to make a separate thread?
One that does not change from version to version. Not even additions would
be allowed. All would have to be done via callbacks. And eventually with
struct versioning. But we do not even allow a TODO discussion board on
php.net somewhere nor did we ever respect our own TODOs.
This IS the discussion board.
So how is this ever going to happen?
So infact if we like something we can either bundle it or have it die.
Ok, so let me summarize it:
to leave PECL/phar in PECL you need a new pluggable API,
and to create the API you need a discussion board,
but even having it you would not discuss the API because nobody respects TODOs.
Did I miss something?
In the past we have bundeled even stuff that has not been stable or in a
mature state.Well, THAT is a nice argument.
We've fucked it up in the past, let's do it again, huh?Phar is stable. All I said is that we won't do the same mistake again.
PECL/json, PECL/zip and the others were/are stable too.
That doesn't mean there are no bugs we don't know of.
Best regards,
Marcus
Hello Antony,
it make it much harder as you would need to load PHP_Archive before
you can do anything else with them. It would mean you cannot easily
execute them unless they contain PHP_Archive themselves....
It's harder for those who create phars, but there is no difference for those who use phars.
--
Wbr,
Antony Dovgal
Now adding Pecl/Zip was a clever idea as it allows an easy way to
compress stuff on the fly for sites that offer downloads. However
this is a) far far away from a mainstream problem and b) we should
not eventhink of turning it into a JAR and hack around PHP all over.
Let's just go with Zip/BZip2/GZ (a sane offer of choices) for on
the fly packing and Phar for deployment. And if some people want to
execute phars directly, then why the hell make it hard for them or
even disallow that?
Please, Marcus don't mix your personal feelings and the question we're discussing here.
PECL/zip has nothing to do with PEAR/phar and it does not matter how "mainstream" is it.
Unfortunately it's already there, so it's too late to discuss whether it was good or bad decision.
And referring to other extensions ("they did it, why can't I do it") is just childish.
--
Wbr,
Antony Dovgal
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
That's fine, the question is why exactly we need fast implementation of
PHP_Archive that can be bundled into PHP as a C extension. I see only
one reason - to run php code in production out of phar, and I don't
think it's a good idea. Any other reasons?
Guys what I don't understand is why some few people bicker around
Phar so much, just because they have no private use for it? In the
Maybe if you actually tried to read the arguments instead of dismissing
them as "bickering" you'd actually see why. I brought forward a number
of reasons and neither of them was "it's of no private use for me". You
can do better than this, really.
past we have bundeled even stuff that has not been stable or in a
mature state.
So we should do that more and more, right? More unstable stuff with
potential for abuse is great for PHP, isn't it?
And I have not seen a single reason against it. The only one close
Maybe you should actually read my emails?
last time I checked PHP worked nearly perfectly. And last time I had
to deal with JARs I did not have the slightest advantage of having
it be a ZIP file. Just because in all those Java formats you have to
You didn't doesn't mean nobody did. You aren't the only programmer in
the universe, you know, and people behind most of the packaging formats
seem strangely united in not inventing new package formats but reusing
old ones with existing tools. I wonder why would that be?
the fly packing and Phar for deployment. And if some people want to
execute phars directly, then why the hell make it hard for them or
even disallow that?
Because it's a bad idea. And nobody disallowing that - we just refrain
from promoting it.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.That's fine, the question is why exactly we need fast implementation of
PHP_Archive that can be bundled into PHP as a C extension. I see only
one reason - to run php code in production out of phar, and I don't
think it's a good idea. Any other reasons?
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able to
maintain a config file and a single file would be quite nice imho.
regards,
Lukas
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able toI know one - PEAR. And it's kinds special because it's library
installer. What others are there?
Documentation and other code analyis tools.
Database management tools.
Code generation tools.
Well I think the first two are more likely, code generation tools tend
to be very tightly coupled with your actual application.
regards,
Lukas
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able toI know one - PEAR. And it's kinds special because it's library
installer. What others are there?
phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator,
php_lexergenerator should I continue?
Greg
Gregory Beaver wrote:
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?phpdocumentor, phpunit, phpcodesniffer, peclgen, php_parsergenerator,
php_lexergenerator should I continue?
I also just realized, these are also all tools where you probably do not
want APC to store the bytecode in memory. Furthermore it is however
still quite useful to have your unit test executing quickly.
regards,
Lukas
I also just realized, these are also all tools where you probably do not
want APC to store the bytecode in memory. Furthermore it is however
still quite useful to have your unit test executing quickly.
How speed of the tests would depend on speed of the loading phpunit
runner? I don't believe reading a couple of files phpunit runner needs
with PHP would do much difference compared to reading same files with C.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
I also just realized, these are also all tools where you probably do
not want APC to store the bytecode in memory. Furthermore it is
however still quite useful to have your unit test executing quickly.How speed of the tests would depend on speed of the loading phpunit
runner? I don't believe reading a couple of files phpunit runner needs
with PHP would do much difference compared to reading same files with C.
Yes, of course if you are looking to run 1 hour worth of unit tests, the
initial load up time is not relevant. But if you just want to quickly
run the tests that you feel are most likely affected, the start up time
is relevant.
regards,
Lukas
include to work on those. Making a hack in PHP to allow "phar://"
streams to work is a bad idea, a C-extension can easily work here.
So from now on, every time we would want to user stream we'd have to do
C extension and all user stream functionality in PHP is just useless?
And all that for some weird reincarnation on safe mode again? I don't
know how it sounds for you, but form be it sounds really broken way to
do things - throwing perfectly good and working userspace streams
because of pseudo-security configurations.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
include to work on those. Making a hack in PHP to allow "phar://"
streams to work is a bad idea, a C-extension can easily work here.So from now on, every time we would want to user stream we'd have to do
C extension and all user stream functionality in PHP is just useless?
And all that for some weird reincarnation on safe mode again? I don't
know how it sounds for you, but form be it sounds really broken way to
do things - throwing perfectly good and working userspace streams
because of pseudo-security configurations.
Hi,
I'd like to remind everyone that I brought up this issue when it was
originally proposed to make userspace streams always remote and to
disable allow_url_fopen/allow_url_include. This was in the days when
Esser was still around, to put it in context.
The only solution that would allow userspace streams to function and
allow security would be to implement safe_mode 2.0: disable all remote
access functions when inside a streams handler. The implementation is
actually quite simple on the surface, but immensely complex in reality,
as it would require combing through every internal PHP function or class
that can possibly access the outside world, and disabling it. Otherwise
users will be able to circumvent all_url_fopen by writing a simple
stream wrapper that just downloads the crap and returns it as an $fp.
However, could we take another look at the purpose of
allow_url_include/fopen? Isn't it to prevent stupid users from shooting
themselves in the foot with code like:
<?php
$a = fopen($_GET['dumbidea']);
include $_GET['waystupididea'];
?>
allow_url_include/allow_url_fopen do not prevent users from downloading
code and executing it intentionally, this is the job of a firewall.
I know the idea of a taint mode was sort of discarded (I think it was,
that was one loooong thread), but realistically, this is probably the
better way to a more secure fopen and include without a more difficult
safe mode-esque solution.
All security experts say security is a tradeoff between convenience and
safety, and the convenience of userspace stream wrappers will simply
disappear in the name of the safety of preventing remote code execution
vulnerabilities.
Thanks,
Greg
The only solution that would allow userspace streams to function and
allow security would be to implement safe_mode 2.0: disable all remote
No, that's not the only solution. Other solution would be stop trying to
do what should be done on entirely other level and do it on the OS
level, not try to make PHP what it is not - PHP is not built to securely
limit the programmer and all attempts to do that eventually lead to the
same problems safe_mode had. Or worse, if they break perfectly good code
on the way.
that can possibly access the outside world, and disabling it. Otherwise
users will be able to circumvent all_url_fopen by writing a simple
stream wrapper that just downloads the crap and returns it as an $fp.
I say if you don't want your users to contact outside world, buy a
firewall. allow_url_include was intended to serve very specific purpose,
to plug hole created by often-written stupid code. It's not a
comprehensive security solution and was not intended to restrict the
programmer.
I know the idea of a taint mode was sort of discarded (I think it was,
Actually, AFAIK it wasn't :)
disappear in the name of the safety of preventing remote code execution
vulnerabilities.
There would be no safety and no prevention, just plugging one way of
thousands. IMHO it is pointless.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would be
very nice here.
Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool.
regards,
Lukas
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would be
very nice here.Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool.
.. even though it does not require Phar extension at all.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a
bunch of
nice sub projects. And even some external (as in non PHP)
applications and
projects make use of it. Providing a better internal infrastructure
would be
very nice here.Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool... even though it does not require Phar extension at all.
Yup, since its only leveraging phar for installation. It would be nice
to also be able to try out a new version of PEAR efficiently without
having to install any files besides running the phar.
regards,
Lukas
Antony Dovgal wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a
bunch of
nice sub projects. And even some external (as in non PHP)
applications and
projects make use of it. Providing a better internal infrastructure
would be
very nice here.Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool... even though it does not require Phar extension at all.
.. and (again) let me be clear:
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.
Without phar, the entire concept that the phar:// stream wrapper is
based upon ceases to be a possibility for wide distribution.
So, yes, this will require the Phar extension or simply cease to exist
as a possibility in the near future.
Greg
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.
I guess we are solving the wrong problem. We have:
- phar needs script-defined named streams
- Named streams are prohibited by some config option
- Let's pretend this stream is not actually what it is
- Let's create whole new extension for that and put it into main PHP
I think this process is wrong. If we have problem with names streams
usage in apps, we should seek solutions there, not invent modules just
to work around the problem we ourselves create. What happens we need
next application using named streams? Another extension into main PHP
source whose purpose is to duplicate PHP code and work around our own
security model?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.I guess we are solving the wrong problem. We have:
- phar needs script-defined named streams
- Named streams are prohibited by some config option
- Let's pretend this stream is not actually what it is
- Let's create whole new extension for that and put it into main PHP
Exactly what I said in IRC earlier today.
Both problem and solution look weird.
I think this process is wrong. If we have problem with names streams
usage in apps, we should seek solutions there, not invent modules just
to work around the problem we ourselves create. What happens we need
next application using named streams? Another extension into main PHP
source whose purpose is to duplicate PHP code and work around our own
security model?
--
Wbr,
Antony Dovgal
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.I guess we are solving the wrong problem. We have:
- phar needs script-defined named streams
- Named streams are prohibited by some config option
- Let's pretend this stream is not actually what it is
- Let's create whole new extension for that and put it into main PHP
Exactly what I said in IRC earlier today.
Both problem and solution look weird.I think this process is wrong. If we have problem with names streams
usage in apps, we should seek solutions there, not invent modules just
to work around the problem we ourselves create. What happens we need
next application using named streams? Another extension into main PHP
source whose purpose is to duplicate PHP code and work around our own
security model?--
Wbr,
Antony Dovgal--
Ok just so there's no confusion.. Here's 2 examples why PEAR and phar
are both useful (If you need more detailed examples (file names, etc I
can also draw up something)
-
Phar:
You can use phar for instance if you deploy all your own scripts, etc.
A normal application without third party libraries bundled (Otherwise
of couse you can store your third script in your phar and just make a
new release when the third-script updates) etc. The idea of the phar
is to make it easy to deploy. Which is good. -
Pear:
Pear has channels which make it really easy to deploy applications
that are depending on different channels (third party scripts) which
make it easy to both install and udpate. You wrap your application in
your package name which you distribute through the SOMENAME.com
channel, then you can also use another channel (the third party
script) by using channel-discover and download/easy update the
third-party scripts using pear upgrade SOMEOTHERCHANNEL.com's package
name.
--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
PHP_Archive-based phar archives will no longer work once
allow_url_include is off and user streams wrappers are marked as remote.
So, it won't work with 100% of new installations in future PHP versions.I guess we are solving the wrong problem. We have:
- phar needs script-defined named streams
- Named streams are prohibited by some config option
- Let's pretend this stream is not actually what it is
- Let's create whole new extension for that and put it into main PHP
I think this process is wrong. If we have problem with names streams usage in
apps, we should seek solutions there, not invent modules just to work around
the problem we ourselves create.
So why don't you come up with a different "better" solution then?
regards,
Derick
So why don't you come up with a different "better" solution then?
Not breaking streams in php 6?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stas, not sure if you are aware of this, but the PEAR installer has
gotten wide adoption as a deployment tool.
Meaning a lot of people are running apps packaged in phar's? Could you
bring forward some examples?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
\For the biggest changes i'd like to see the following:
- Adding PECL/Phar as default extension
I really don't think we need phar in core, certainly not enabled by
default. If someone can make a good case for including it, I'd love
to hear it.Easier distributing/deployment of stuff and phar even allows to use
the
packed files as is from within the package or unpacked without any
change. We use phar already for pear. Having the extension version
that
allows the mentioned untouched unpacking feature would help a lot of
people.
Sure, that's why the Phar is there, I don't contest that it is a
useful extension, but so are dozens of others inside PECL. To me it
does not mean every extension that is at all useful should be
included into the standard distro. If anything having in PECL allows
for quicker releases and easier upgrade process, since people will
mostly compile it in if it is in core, while pecl will 99% of the
time be a shared extension. This means built-in version will require
a PHP recompile to upgrade, something most people will not do, making
them use older, possibly buggy versions.
- Add open_filename debug info to streams
What would this mean for performance and memory usage of file ops?
An additional malloc and strcpy on opening and an additional free
on closing. We could however limit actual use to --enable-debug
builds.
My preference we enable this feature only for debug builds.
Ilia Alshanetsky
- Add open_filename debug info to streams
What would this mean for performance and memory usage of file ops?
An additional malloc and strcpy on opening and an additional free
on closing. We could however limit actual use to --enable-debug
builds.My preference we enable this feature only for debug builds.
There might be users for whom debug info in production is way more
important than raw performance...
I dunno how expensive (malloc + strcopy + free) is, but it doesn't
seem to this naive reader like it's going to swamp a server, if
somebody who knows what they are doing wants that on even in
production.
I could easily be under-estimating the expense, but it just seems like
there's a lot more PHP scripts that need a lot more better debugging
code more than they need raw performance.
I'm not claiming that having this available will stop any idiots from
writing bad code, but it might help a couple smart folks write better
code.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
IMHO one good reason to start a new branch for 5.x would be the
ability to get rid off register_globals and magic_quotes in the 5
series without having to wait for PHP6 to come around.
Ilia
IMHO one good reason to start a new branch for 5.x would be the
ability to get rid off register_globals and magic_quotes in the 5
series without having to wait for PHP6 to come around.
That's exactly the reason I'm against creating 5_3 branch at this moment -
I'm afraid that you (and everybody else) will start patching it and 5_2 will
become 4_4 as it is now - security fixes only.. once in a month.. maybe.. or maybe not.
You would be busy with 5_3, even though there is enough work in 5_2 branch.
--
Wbr,
Antony Dovgal
IMHO one good reason to start a new branch for 5.x would be the ability to
get rid off register_globals and magic_quotes in the 5 series without
having to wait for PHP6 to come around.That's exactly the reason I'm against creating 5_3 branch at this moment - I'm
afraid that you (and everybody else) will start patching it and 5_2 will
become 4_4 as it is now - security fixes only.. once in a month.. maybe.. or
maybe not.
You would be busy with 5_3, even though there is enough work in 5_2 branch.
Yes, and development should not be done in a branch anyway, but in HEAD.
regards,
Derick
Ilia Alshanetsky wrote:
IMHO one good reason to start a new branch for 5.x would be the ability
to get rid off register_globals and magic_quotes in the 5 series without
having to wait for PHP6 to come around.
What would be the goal of that? Making it less painful to migrate to PHP
6.x since they already face similar pain when staying in the active 5.x
branch?
regards,
Lukas
Ilia Alshanetsky wrote:
IMHO one good reason to start a new branch for 5.x would be the ability to
get rid off register_globals and magic_quotes in the 5 series without having
to wait for PHP6 to come around.What would be the goal of that? Making it less painful to migrate to PHP 6.x
since they already face similar pain when staying in the active 5.x branch?
Well, as you know some developers do not really care about PHP 6 and
just leave it lying around without the proper merged from stuff that are
put in PHP_5_2 at the moment. IMO this is just another attempt to stall
PHP 6 developed (and adoption).
I would be against merging those two things back to PHP_5_2. There is no
compelling reason to do so.
However, something that is a good reason is some lower level engine
stuff that people will actually benefit from.
regards,
Derick
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
-----Original Message-----
From: Ilia Alshanetsky [mailto:ilia@prohost.org]
Sent: Sunday, May 06, 2007 11:12 AM
To: Marcus Boerger
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Starting 5.3IMHO one good reason to start a new branch for 5.x would be
the ability to get rid off register_globals and magic_quotes
in the 5 series without having to wait for PHP6 to come around.Ilia
--
To
unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.IMHO one good reason to start a new branch for 5.x would be
the ability to get rid off register_globals and magic_quotes
in the 5 series without having to wait for PHP6 to come around.
It seems to me that there are even more people around with their own agendas
today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've
stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for
me, so my next step WOULD be PHP6. For those of us who have already 'dropped'
register_globals and magic_quotes in our code, forcing people who have not yet
had time to make the move seems a little heavy handed. PHP6 will need a major
porting exercise, so keep it until then.
As for phar? It sounds a little like PDO. No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support. Proper discussion and development of elements
that are planned to become main stream would be nice, and not the apparently
current method of 'I'm doing this in the next release because I want it!' Do
we need phar? Is it fully operational on all platforms? How will the currently
registered dependencies be addressed? IF it goes into the main distribution
presumably the installers are going to be extended to support it's server
requirements. Is that appropriate 'mid cycle'?
It WOULD be nice to spend some time inside the PHP code base, but at present
all spare time seems to be spent monitoring and testing all the changes to the
releases and always playing catch up.
PHP6 is the next release - PHP5 should now be tied down and put on the same
basis as PHP4 before we end up with even more private initiatives creating
even more mayhem :(
If people want these changes why aren't they working to get PHP6 out?
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.IMHO one good reason to start a new branch for 5.x would be the ability to
get rid off register_globals and magic_quotes in the 5 series without
having to wait for PHP6 to come around.It seems to me that there are even more people around with their own agendas
today. The PHP6 'plan' is looking good, but do we have an ETA? Personally I've
stopped bothering with all the changes to PHP5 and 5.1.6 is working nicely for
me, so my next step WOULD be PHP6. For those of us who have already 'dropped'
register_globals and magic_quotes in our code, forcing people who have not yet
had time to make the move seems a little heavy handed. PHP6 will need a major
porting exercise, so keep it until then.As for phar? It sounds a little like PDO. No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support. Proper discussion and development of elements
that are planned to become main stream would be nice, and not the apparently
current method of 'I'm doing this in the next release because I want it!' Do
we need phar? Is it fully operational on all platforms? How will the currently
registered dependencies be addressed? IF it goes into the main distribution
presumably the installers are going to be extended to support it's server
requirements. Is that appropriate 'mid cycle'?It WOULD be nice to spend some time inside the PHP code base, but at present
all spare time seems to be spent monitoring and testing all the changes to the
releases and always playing catch up.PHP6 is the next release - PHP5 should now be tied down and put on the same
basis as PHP4 before we end up with even more private initiatives creating
even more mayhem :(
If people want these changes why aren't they working to get PHP6 out?
Amen, besides that you should use php 5.2 and not 5.1.6 ;-)
regards,
Derick
Derick Rethans wrote:
PHP6 is the next release - PHP5 should now be tied down and put on the same
basis as PHP4 before we end up with even more private initiatives creating
even more mayhem :(
If people want these changes why aren't they working to get PHP6 out?Amen, besides that you should use php 5.2 and not 5.1.6 ;-)
Perhaps when I get some time to find out why the code will not run on 5.2 but
is fine on 5.1.6 ;)
But now need to set the test machine up with 5.2.2 and start testing again. If
we knew that there were no problems installing an update life would be easier,
but the time it takes to fully test all options every time simply BECAUSE we
know things will need changing .....
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Lester Caine wrote:
As for phar? It sounds a little like PDO. No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support. Proper discussion and development of
elements that are planned to become main stream would be nice, and not
the apparently current method of 'I'm doing this in the next release
because I want it!' Do we need phar? Is it fully operational on all
platforms? How will the currently registered dependencies be addressed?
IF it goes into the main distribution presumably the installers are
going to be extended to support it's server requirements. Is that
appropriate 'mid cycle'?
Hi Lester,
Phar does not require any external dependencies to read .phar files.
Optional extension dependencies include SPL and hash. It is fully
operational on all platforms because it uses the streams layer to read
the underlying .phar file, and it has no "server requirements"
It may be helpful to understand where phar came from. I've been happily
developing PHP_Archive (http://pear.php.net/PHP_Archive) and using it to
package up PEAR releases since PHP 5.2.0 - in production. PHP_Archive
relies upon a user stream wrapper to function, but works great.
Unfortunately, as of PHP 6, the plan is to mark all user streams as
being remote, regardless of what they actually do. Because of this,
PHP_Archive will no longer work on any system without php.ini changes.
This effectively kills the format. The phar extension, being a C-based
extension, is allowed to mark itself as a local, non-remote stream, and
will therefore still work.
Phar has had many extra features added since this original porting of
PHP -> C. One of the significant features allows a mapping of a phar to
its extracted location on disk. There are plans to implement a simple
but effective (optional) front controller function to simplify pharring
of web apps.
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.
Greg
Gregory Beaver wrote:
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.
The 'comparison' was in the way these packages get added without proper
investigation ;) Someone decides that THIS is how it will be done, and that is
what happens :( and we have to live with the consequences.
How would I use 'phar' with the four thousand files that make up bitweaver? I
have had a quick look, but I don't yet see how I handle all the installation
and management options for installing and updating packages that bitweaver has
been designed to support. ADOdb and smarty provide the core libraries, and the
liberty shell is built on those. Only those packages that are needed are
download to the target system. I suspect we would have to build phar files for
each package, but currently styles and themes can easily be managed via a few
file changes, something that phar would seem to make a lot more difficult.
Private tweaks to the libraries provide performance and operational
improvements that would not be possible if ADOdb or smarty were supplied
'packed'. But without example phar libraries to look at and pull apart proper
investigation is difficult - as people have already said.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Lester Caine wrote:
Gregory Beaver wrote:
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.The 'comparison' was in the way these packages get added without proper
investigation ;) Someone decides that THIS is how it will be done, and
that is what happens :( and we have to live with the consequences.
Please, this is ridiculous, your response is completely out of
proportion to what is happening. Marcus proposed the addition of phar
to core in 5.3, and is now asking for public comment.
How would I use 'phar' with the four thousand files that make up
bitweaver? I have had a quick look, but I don't yet see how I handle all
the installation and management options for installing and updating
packages that bitweaver has been designed to support. ADOdb and smarty
provide the core libraries, and the liberty shell is built on those.
Only those packages that are needed are download to the target system. I
suspect we would have to build phar files for each package, but
currently styles and themes can easily be managed via a few file
changes, something that phar would seem to make a lot more difficult.
Private tweaks to the libraries provide performance and operational
improvements that would not be possible if ADOdb or smarty were supplied
'packed'. But without example phar libraries to look at and pull apart
proper investigation is difficult - as people have already said.
phar is best for self-contained libraries or applications that do not
need to modify their source code. Many applications (like phpmyadmin)
do configuration by modifying a source code file and then including it.
This practice would require that the phar.read_only INI setting be off
in php.ini (it is on by default).
Also useful and not yet implemented would be to allow include_path to
have a phar:// archive, as many issues with "pharring" applications
would no longer exist. Controversy doesn't even begin to describe the
reaction I expect from this suggestion, however.
Thanks,
Greg
Lester Caine wrote:
Andi Gutmans wrote:
I see no value in making compatibility breaks in 5.x and not in the next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.IMHO one good reason to start a new branch for 5.x would be the
ability to get rid off register_globals and magic_quotes in the 5
series without having to wait for PHP6 to come around.It seems to me that there are even more people around with their own
agendas today.
I don't think there are that many agendas, just more constituents of each.
-
admins who don't want binary compatibility breaks on subversion bumps,
lest they start rebuilding all sorts of things beyond php itself. -
admins and users who are sick of having things that 'just worked' broken
even at a subversion bump, and who don't want to see anything deprecated
until PHP6. -
security folk who want frequently-abused features deprecated yesterday.
-
users who want the bleeding edge new toys and features.
and -most importantly-
-
developers who want to implement new toys and push them out there to the
admin and user communities tomorrow. Pride of authorship, usefulness,
encouraging the health of the community, and all that. -
developers who want to constrain growth so that the users have a more
stable platform to use and they can follow all of the changes.
They are most important because PHP -is- its developers. The only question,
how to reconcile this most critical constituency with the other communities,
such that all of the communities are mostly-happy.
This probably only works if things don't get broken between 5.2.2 and 5.2.3,
only absolutely manditory breakage occurs from 5.2 to 5.3, some wiggle room
for cool new things is left open in 5.2.3 and 5.3, and finally that some of
the more 'international' devs, users and admins work focus together on a 6.0
end-result, since they are the ones who needed the unicode implementation about
five years ago.
These are the same battles we all face at many projects (I'm hidden over at
httpd, apr, etc etc) and the conclusion is usually the same. Pick a versioning
policy, stick to it, and otherwise don't get in the way of dev's enthusiasm.
[If any users/admins are insulted, mea culpa. Consider that there would be
no PHP for you to use/admin without your dedicated developers. It's open
source - if it broke, you still have both halves.]
No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support.
Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebird at each conference and I've never had more
than about 1 in 50 people admit to ever having used it, and those are
shaky hands going up--we're not talking die-hard firebird users here.
As for PDO missing pieces for Firebird, that's also untrue.
Perhaps you don't understand the PDO architecture, but PDO was
designed by taking into account every database client API; it has
hooks to cater for just about every conceivable way of passing data
into and out of a database API.
It's the firebird driver that needs work.
--Wez.
Wez Furlong wrote:
No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support.Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebird at each conference and I've never had more
than about 1 in 50 people admit to ever having used it, and those are
shaky hands going up--we're not talking die-hard firebird users here.
From my experience Firebird users are quite regionally distributed
across Brazil and Russia. But anyways, the problem is of course not that
we are uninterested in Firebird, but simply that nobody with the C
hacker skills has taken this over yet.
regards,
Lukas
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
"no one" uses it.
--Wez.
But anyways, the problem is of course not that
we are uninterested in Firebird, but simply that nobody with the C
hacker skills has taken this over yet.regards,
Lukas
Wez Furlong wrote:
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
"no one" uses it.
I would not say that on the firebird-php list Wez - one hell of a lot of
people rely on it for their livelyhood. I know - I'm one of them.
I don't have time to waste to move perfectly functional code from one driver
to another just because others say that is what must happen. I'll stick with
the driver that IS working, and uses the optimal method of getting SQL in
and out of the engine rather than having to take a second best route.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Lester Caine wrote:
Wez Furlong wrote:
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
"no one" uses it.I would not say that on the firebird-php list Wez - one hell of a lot of
people rely on it for their livelyhood. I know - I'm one of them.
I don't have time to waste to move perfectly functional code from one
driver to another just because others say that is what must happen. I'll
stick with the driver that IS working, and uses the optimal method of
getting SQL in and out of the engine rather than having to take a second
best route.
Lester, the point is simple. Very few things in PHP get done because
someone besides the actual developer needs it. In some cases this "need"
is created by a corporate sponsor as in the case of the oci8 driver. But
you can argue all you want on this, the fact of the matter is that
"importance" in PHP is determined by the assumption that anything
important will have someone to hack on. Of course some "important"
things might just be unlucky in this setup and Firebird seems to be hit
by that.
So I suggest that you go hunt on firebird-php for some people with
hacking skills, that are interested in playing with PDO. That being
said, you are right the native extensions are slightly faster (unless
you are making heavy use of fetchAll()) and they work nice and provide
more features. That beind said, a lot of shiny new software is build on
top of PDO and if nobody in the Firebird community picks up the PDO
driver, all the Firebird users will be left out in the cold. But again,
if nobody with C hacking skills is feeling sufficient pain over this,
the assumption is that the pool of users is too small or the pain is too
small.
regards,
Lukas
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over this,
the assumption is that the pool of users is too small or the pain is too
small.
Hi,
sorry for such late reply, but I just joined this group. I'm very
interested in Firebird's future in PHP and I have C skills. However, to
answer your assumption: the pain is too small.
We have a working 'interbase' extenstion that does all the job, and does
it well. I see that it might get moved to PECL or it might not, however,
it is going to be working for a long time. Current PHP+Firebird users
just don't feel that they need PDO.
It could be used for new application development, but you'll hardly find
a novice PHP user that is also willing to start hacking into PHP source
code in parallel. Existing users are simply happy with pure ibase_
functions and ADOdb.
Now, I don't know about that 'lot of shiny new software' being written
on PDO, and don't really see that Firebird users will care much. Most of
that software is meant to run for ISPs, hosting, etc. services and
Firebird is still not on par with MySQL in that (web hosting)
environment. I use Firebird for everything, except dynamic online
websites where MySQL is simply the best choice.
I hope that PDO stuff is not meant to completely replace mysql_, ibase_,
etc. kind of functions in some distant future.
--
Milan Babuskov
http://www.flamerobin.org
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over
this, the assumption is that the pool of users is too small or the
pain is too small.sorry for such late reply, but I just joined this group. I'm very
interested in Firebird's future in PHP and I have C skills. However,
to answer your assumption: the pain is too small.We have a working 'interbase' extenstion that does all the job, and
does it well. I see that it might get moved to PECL or it might not,
however, it is going to be working for a long time. Current PHP
+Firebird users just don't feel that they need PDO.It could be used for new application development, but you'll hardly
find a novice PHP user that is also willing to start hacking into
PHP source code in parallel. Existing users are simply happy with
pure ibase_ functions and ADOdb.Now, I don't know about that 'lot of shiny new software' being
written on PDO, and don't really see that Firebird users will care
much. Most of that software is meant to run for ISPs, hosting, etc.
services and Firebird is still not on par with MySQL in that (web
hosting) environment. I use Firebird for everything, except dynamic
online websites where MySQL is simply the best choice.
Its not only shiny software, its pretty much all of the standard libs
people are developing. So even if you use PHP+Firebird for other stuff
you will probably be unhappy that you cannot really use any of the
database enabled libs in ezc and ZF. The same will probably be true
for PEAR2 etc.
I hope that PDO stuff is not meant to completely replace mysql_,
ibase_, etc. kind of functions in some distant future.
It does not seem like its going to happen in the immediate future (aka
PHP 6.0) unless we will that we have nobody to contact in case of bugs
and more importantly that ensures that we are aware of security
issues. So for now it would be sufficient someone steps up and takes
over the maintainer role for the ibase extension. This would entail
doing the standard maintenance stuff like updating to the new
parameter parsing API. It would also entail proactively addressing
security issues. Obviously for PHP 6.0 we do need someone to update
things for full unicode support eventually as well.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over this, the
assumption is that the pool of users is too small or the pain is too small.Hi,
sorry for such late reply, but I just joined this group. I'm very interested
in Firebird's future in PHP and I have C skills. However, to answer your
assumption: the pain is too small.
How should we understand that? Too small to actually take care of it?
With the risk to repeat myself, the goal is to have a long term
working extension with maintainer(s). An extension without
maintainers, especially DB related extensions (or service specific
extension) will slowly die within a couple of years if nothing is
done.
Let forget PDO for now, that's not the point (even if a working
firebird support for PDO would rock).
Cheers,
Pierre
Pierre Joye wrote:
if nobody with C hacking skills is feeling sufficient pain over this, the
assumption is that the pool of users is too small or the pain is too small.sorry for such late reply, but I just joined this group. I'm very interested
in Firebird's future in PHP and I have C skills. However, to answer your
assumption: the pain is too small.How should we understand that? Too small to actually take care of it?
Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO
support for Firebird. If would be great pain not to have php_interbase,
and if nobody is out there willing to do it, I'd like to step up.
What are the requirements for someone to become an extension maintainer?
With the risk to repeat myself, the goal is to have a long term
working extension with maintainer(s). An extension without
maintainers, especially DB related extensions (or service specific
extension) will slowly die within a couple of years if nothing is
done.Let forget PDO for now, that's not the point (even if a working
firebird support for PDO would rock).
Ok.
What do I need to become a maintainer of php_interbase?
I got C/C++ skills and an very familiar with Firebird (I'm part of the
team that makes FlameRobin, which is an open source cross-platform C++
admin. tool for Firebird). I have access to Linux and Windows XP.
Although I prefer Linux for development, I could compile something with
MSVC Express Edition if/when it's really needed.
Now, when we're at it, my experience with MSVC and Windows command line
tools is almost none. I tried to build PHP 5.3 with it, but the guide on
PHP website has some errors (some stuff just isn't where it says it is,
and it seems some steps are skipped. Also, the 'configure' script used
for MSVC fails to detect that those things are missing). Where should I
report such problems? (Is this list appropriate for such questions)?
Thanks,
--
Milan Babuskov
http://www.flamerobin.org
Hi!
Now, when we're at it, my experience with MSVC and Windows command line
tools is almost none. I tried to build PHP 5.3 with it, but the guide on
PHP website has some errors (some stuff just isn't where it says it is,
and it seems some steps are skipped. Also, the 'configure' script used
for MSVC fails to detect that those things are missing). Where should I
report such problems? (Is this list appropriate for such questions)?
In general, building PHP on windows should be as easy as on Unix, not
requiring any special knowledge of the tools, meaning:
- Get environment with MSVC set up
- Get external libraries (recommended to put them in same upper-level
dir as php checkout) - Run buildconf
- Run cscript configure.js --options
- Run nmake
- Enjoy your PHP build
If something doesn't work along the way, most probably some library is
missing or wrong version, etc. There's now dedicated windows list
internals-win@lists.php.net, which might be a better place for
discussing it, but in any case description of the error message would help.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Stanislav Malyshev wrote:
In general, building PHP on windows should be as easy as on Unix, not
requiring any special knowledge of the tools, meaning:
- Get environment with MSVC set up
- Get external libraries (recommended to put them in same upper-level
dir as php checkout)- Run buildconf
- Run cscript configure.js --options
- Run nmake
When I run nmake, it has a line that starts with "" instead of some
command name. Looking at the configure.js script, it seems that it
cannot find something called mc.exe on my system (no wonder since I
don't have it), but it goes forward happily without any errors.
I managed to learn little about mc.exe using Google. It's some kind of
Message Compiler by Microsoft. Any idea what do I need to install to get
mc.exe?
It may seem that MSVC install is broken, but I can build wxWidgets and
FlameRobin with it without any problems. I have MSVC 9 Express Edition.
If something doesn't work along the way, most probably some library is
missing or wrong version, etc. There's now dedicated windows list
internals-win@lists.php.net, which might be a better place for
discussing it, but in any case description of the error message would help.
Ok, thanks.
--
Milan Babuskov
http://www.flamerobin.org
Pierre Joye wrote:
if nobody with C hacking skills is feeling sufficient pain over this,
the
assumption is that the pool of users is too small or the pain is too
small.sorry for such late reply, but I just joined this group. I'm very
interested
in Firebird's future in PHP and I have C skills. However, to answer your
assumption: the pain is too small.How should we understand that? Too small to actually take care of it?
Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO
support for Firebird. If would be great pain not to have php_interbase, and
if nobody is out there willing to do it, I'd like to step up.What are the requirements for someone to become an extension maintainer?
With the risk to repeat myself, the goal is to have a long term
working extension with maintainer(s). An extension without
maintainers, especially DB related extensions (or service specific
extension) will slowly die within a couple of years if nothing is
done.Let forget PDO for now, that's not the point (even if a working
firebird support for PDO would rock).Ok.
What do I need to become a maintainer of php_interbase?
Motivation and a some free time (happiness too :)
Now, when we're at it, my experience with MSVC and Windows command line
tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP
website has some errors (some stuff just isn't where it says it is, and it
seems some steps are skipped. Also, the 'configure' script used for MSVC
fails to detect that those things are missing). Where should I report such
problems? (Is this list appropriate for such questions)?
You don't have to be a windows pro as long as you can test it on
windows. The main problem now is that we had no maintainer to take
care of the bugs (there is bugs), to valid a release (sources or
binary), etc.
Are you (still) interested? :)
--
Pierre
Pierre Joye wrote:
You don't have to be a windows pro as long as you can test it on
windows. The main problem now is that we had no maintainer to take
care of the bugs (there is bugs), to valid a release (sources or
binary), etc.Are you (still) interested? :)
Yes.
I'll report back when I get a working PHP build on Windows, and then
someone could tell me what needs to be done exactly to get going.
Thanks,
--
Milan Babuskov
http://www.flamerobin.org
Wez Furlong wrote:
No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support.Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebird at each conference and I've never had more
than about 1 in 50 people admit to ever having used it, and those are
shaky hands going up--we're not talking die-hard firebird users here.As for PDO missing pieces for Firebird, that's also untrue.
Perhaps you don't understand the PDO architecture, but PDO was
designed by taking into account every database client API; it has
hooks to cater for just about every conceivable way of passing data
into and out of a database API.It's the firebird driver that needs work.
No Wez - As far as I am concerned I need to load the non PDO driver for those
areas that PDO does not support. As well as the PDO driver for the data based
stuff IF I wanted to go down that route. But at present there is no good
reason to switch.
User security, Event management, Services interface functions are not data
based and while some of those functions are being moved into the Firebird SQL,
things like Events can not go that route.
Now you may think that everything at the database end should be controlled via
SQL, and that is probably the case, but as we have discussed long ago, WE
still need ADOdb to provide the SQL abstraction so there is little incentive
to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is
fine and are currently working ( and ADOdbLite is the 'compact' version ).
While ADOdb does support PDO, the best performance is still obtained with the
raw drivers for each engine. If we are NOT working with multiple engines, then
we work with the raw driver so again there is little need to spend scarce time
replacing something that is working and has more facilities.
So until you provide a very good reason why we need to change - it's not going
to happen. BLOB and parameter handling in the raw Firebird driver are a lot
more flexible and simply sending a query with an optional array of parameters
is much easier than HAVING to prepare everything - especially when the engine
will cache things automatically anyway.
PDO simply changes the ground rules without solving any particular problem as
has been said all along. Now you may well convince people that all the native
drivers should be dropped from PHP and only PDO supplied but I hope that does
not happen and that we have a PROPER debate on an abstract database layer.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Lester Caine wrote:
PDO simply changes the ground rules without solving any particular
problem as has been said all along. Now you may well convince people
that all the native drivers should be dropped from PHP and only PDO
supplied but I hope that does not happen and that we have a PROPER
debate on an abstract database layer.
One of the dream features back in the early days of PDO was a way to get
a "native extension" connection out of PDO. Unfortunately this turned
out to be impossible(?) to do :(
regards,
Lukas
Lukas Kahwe Smith wrote:
Lester Caine wrote:
PDO simply changes the ground rules without solving any particular
problem as has been said all along. Now you may well convince people
that all the native drivers should be dropped from PHP and only PDO
supplied but I hope that does not happen and that we have a PROPER
debate on an abstract database layer.One of the dream features back in the early days of PDO was a way to get
a "native extension" connection out of PDO. Unfortunately this turned
out to be impossible(?) to do :(
I don't think the target is unrealistic, I just think the structure of PDO is
the wrong starting point. But then I am happy working with ADOdb so perhaps
I'm coming from the wrong side. The projects I'm working with run on a
selection of databases out of the box without any difficulty - and don't need
PDO to do so, so there is no incentive to change.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
The point you're missing is that those features all belong in the
firebird driver, not in PDO itself.
--Wez.
Wez Furlong wrote:
No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support.Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebird at each conference and I've never had more
than about 1 in 50 people admit to ever having used it, and those are
shaky hands going up--we're not talking die-hard firebird users here.As for PDO missing pieces for Firebird, that's also untrue.
Perhaps you don't understand the PDO architecture, but PDO was
designed by taking into account every database client API; it has
hooks to cater for just about every conceivable way of passing data
into and out of a database API.It's the firebird driver that needs work.
No Wez - As far as I am concerned I need to load the non PDO driver for those
areas that PDO does not support. As well as the PDO driver for the data based
stuff IF I wanted to go down that route. But at present there is no good
reason to switch.User security, Event management, Services interface functions are not data
based and while some of those functions are being moved into the Firebird SQL,
things like Events can not go that route.Now you may think that everything at the database end should be controlled via
SQL, and that is probably the case, but as we have discussed long ago, WE
still need ADOdb to provide the SQL abstraction so there is little incentive
to work on PDO/Firebird/ADOdb when the current Firebird/ADOdb combination is
fine and are currently working ( and ADOdbLite is the 'compact' version ).
While ADOdb does support PDO, the best performance is still obtained with the
raw drivers for each engine. If we are NOT working with multiple engines, then
we work with the raw driver so again there is little need to spend scarce time
replacing something that is working and has more facilities.So until you provide a very good reason why we need to change - it's not going
to happen. BLOB and parameter handling in the raw Firebird driver are a lot
more flexible and simply sending a query with an optional array of parameters
is much easier than HAVING to prepare everything - especially when the engine
will cache things automatically anyway.PDO simply changes the ground rules without solving any particular problem as
has been said all along. Now you may well convince people that all the native
drivers should be dropped from PHP and only PDO supplied but I hope that does
not happen and that we have a PROPER debate on an abstract database layer.--
Lester Caine - G8HFLContact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
I see no value in making compatibility breaks in 5.x and not in the
next
major version. As it is we drive a lot of our users crazy. We already
agreed this is a 6.x thing.
+1
If there has to be a 5.3, I'd want to see features that:
are incredibly useful/important to the masses (input filtering)
aren't easily tweaked in 5.2.x
don't break anything (i.e., only new functions/extensions/features)
If that ends up being an empty set, then don't even mess with 5.3 and
focus on 6.0 :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
- Add open_filename debug info to streams
What is this feature and how is it different from stream->orig_path
that has been around for several releases?
--Wez.
Hello Wez,
one is doing this:
stream->orig_path = estrdup(opened_path);
the other something else:
stream->open_filename = __zend_orig_filename ? __zend_orig_filename : __zend_filename;
stream->open_lineno = __zend_orig_lineno ? __zend_orig_lineno : __zend_lineno;
best regards
marcus
Wednesday, May 23, 2007, 6:38:59 AM, you wrote:
- Add open_filename debug info to streams
What is this feature and how is it different from stream->orig_path
that has been around for several releases?
--Wez.
Best regards,
Marcus