[RFC] Starting 5.3

18 years ago by Marcus Boerger — view source

unread

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_STRICT into E_STRICT and E_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

18 years ago by Edin Kadribasic — view source

unread

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_STRICT into E_STRICT and E_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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Ilia Alshanetsky — view source

unread

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_STRICT into E_STRICT and E_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

18 years ago by Marcus Boerger — view source

unread

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_STRICT into E_STRICT and E_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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Edin Kadribasic — view source

unread

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 using pecl 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

18 years ago by Ilia Alshanetsky — view source

unread

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 using pecl 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

18 years ago by Antony Dovgal — view source

unread

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 using pecl 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

18 years ago by Edin Kadribasic — view source

unread

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 using pecl 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

18 years ago by Antony Dovgal — view source

unread

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 using pecl 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

18 years ago by Edin Kadribasic — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Oliver Block — view source

unread

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

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Oliver Block — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Oliver Block — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by David Coallier — view source

unread

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...

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

18 years ago by Lukas Kahwe Smith — view source

unread

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 using pecl 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

18 years ago by Ilia Alshanetsky — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Oliver Block — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Andi Gutmans — view source

unread

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.3

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

--
To
unsubscribe, visit: http://www.php.net/unsub.php

18 years ago by Marcus Boerger — view source

unread

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.3

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

--
To
unsubscribe, visit: http://www.php.net/unsub.php

Best regards,
Marcus

18 years ago by Andi Gutmans — view source

unread

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.3

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.3

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

--
To
unsubscribe,
visit: http://www.php.net/unsub.php

Best regards,
Marcus

18 years ago by Davey Shafik — view source

unread

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.3

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

--
To
unsubscribe, visit: http://www.php.net/unsub.php

Best regards,
Marcus

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Davey Shafik — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Davey Shafik — view source

unread

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
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.

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

18 years ago by Pierre — view source

unread

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
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.

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

18 years ago by Marcus Boerger — view source

unread

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
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.

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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 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.

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

18 years ago by Pierre — view source

unread

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
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.

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Andi Gutmans — view source

unread

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
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/

--
To
unsubscribe, visit: http://www.php.net/unsub.php

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by David Coallier — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Pierre — view source

unread

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 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.

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Pierre — view source

unread

Hi,

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.

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

18 years ago by Stanislav Malyshev — view source

unread

.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/

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Pierre — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Pierre — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Gregory Beaver — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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?

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

18 years ago by Gregory Beaver — view source

unread

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?

Greg

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Gregory Beaver — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Gregory Beaver — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by David Coallier — view source

unread

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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Stanislav Malyshev — view source

unread

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/

18 years ago by Ilia Alshanetsky — view source

unread

\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

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Ilia Alshanetsky — view source

unread

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

18 years ago by Antony Dovgal — view source

unread

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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Andi Gutmans — view source

unread

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.3

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

--
To
unsubscribe, visit: http://www.php.net/unsub.php

18 years ago by Lester Caine — view source

unread

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

18 years ago by Derick Rethans — view source

unread

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

18 years ago by Lester Caine — view source

unread

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

18 years ago by Gregory Beaver — view source

unread

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

18 years ago by Lester Caine — view source

unread

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

18 years ago by Gregory Beaver — view source

unread

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

18 years ago by William A. Rowe — view source

unread

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.]

18 years ago by Wez Furlong — view source

unread

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.

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Wez Furlong — view source

unread

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

18 years ago by Lester Caine — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

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

17 years ago by Milan Babuskov — view source

unread

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

17 years ago by Lukas Kahwe Smith — view source

unread

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

17 years ago by Pierre Joye — view source

unread

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

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Milan Babuskov — view source

unread

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

17 years ago by Stanislav Malyshev — view source

unread

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

17 years ago by Milan Babuskov — view source

unread

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

17 years ago by Pierre Joye — view source

unread

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

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Milan Babuskov — view source

unread

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

18 years ago by Lester Caine — view source

unread

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

18 years ago by Lukas Kahwe Smith — view source

unread

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

18 years ago by Lester Caine — view source

unread

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

18 years ago by Wez Furlong — view source

unread

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 - 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

18 years ago by Richard Lynch — view source

unread

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?

18 years ago by Wez Furlong — view source

unread

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.

18 years ago by Marcus Boerger — view source

unread

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

18 years ago by Stanislav Malyshev — view source

unread

PHP-based software, installing a PECL extension is not an option. If I
cannot be sure that phar works on my client's system, I cannot use it to
deploy software.

Unless your clients immediately upgrade to php 5.3 this is the case
anyway for some time (probably measured in years).

Uploading a phar file, then pointing your browser to it and running a
PHP-based self-extracting installer similar to the Windows installers we
know would make installing PHP software way more end-user-compatible.

If it's the installer question you could do it in a number of other
ways, but phar way is OK too. It would be one thing to use phar-like
format as a packaging format used as base for installers (akin to .msi,
.rpm, etc) - and as I understand, it is achievable even without having
phar extension with the same success (performance is not really a thing
for installer). However, running live app from inside phar is entirely
different thing.

IMHO phar should be part of the PHP code, so that developers can rely on
it as a means of PHP software deployment that certainly works on all
systems, rather than another option.

That's exactly what I am saying - that in my opinion such format is not
the best thing PHP software developers could (or should) rely on in many
scenarios. Putting something in PHP source is a form of endorsement, and
I think it should be carefully considered if it's ready for all
scenarios before we do that.

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/

18 years ago by Marcus Boerger — view source

unread

Hello Stanislav,

Monday, May 7, 2007, 10:04:16 AM, you wrote:

PHP-based software, installing a PECL extension is not an option. If I
cannot be sure that phar works on my client's system, I cannot use it to
deploy software.

Unless your clients immediately upgrade to php 5.3 this is the case
anyway for some time (probably measured in years).

I guess we immediately stop unicode development then.

Best regards,
Marcus

18 years ago by Lester Caine — view source

unread

Stefan Priebsch wrote:

phar is a good way of deploying PHP code, as PEAR proves. As a cautious
developer however, I am reluctant to using optional features that might
not be available on my client's installation. And for regular users of
PHP-based software, installing a PECL extension is not an option. If I
cannot be sure that phar works on my client's system, I cannot use it to
deploy software.

Uploading a phar file, then pointing your browser to it and running a
PHP-based self-extracting installer similar to the Windows installers we
know would make installing PHP software way more end-user-compatible.

And given the problem getting hosts to ADD PECL extensions, you expect that
they will allow a third party application to install things on their locked
down machines. I think the first problem is how does it integrate with hosting
environments and will those hosts allow it to run?

IMHO phar should be part of the PHP code, so that developers can rely on
it as a means of PHP software deployment that certainly works on all
systems, rather than another option.

--
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

18 years ago by Pierre — view source

unread

Hi Stefan,

Stanislav Malyshev schrieb:

Unless your clients immediately upgrade to php 5.3 this is the case
anyway for some time (probably measured in years).

Sure. But since PHP4 support is discontinued by the end of this year,
people will have to upgrade to 5.x (or 6) anyway. That would put phar
support in the broad field maybe by mid-year 2008.

When have we announce that PHP4 support will end by the end of this year?

Secondly, expecting than a non existent 5.3 will be the widely used
php release in one year sounds wrong to me :)

--Pierre

18 years ago by Stanislav Malyshev — view source

unread

I fully agree to that. I (currently) see phar as a means of deploying
PHP code. But when people start running PHP apps from a phar, I am sure

Then you don't need any extension - install should run without it quite
well.

And, if APC becomes more wide-spread in the future, I guess it does not
really matter wether the code is read from filesystem of phar for the

It does. For starters, if you put whole multi-megabyte app in one file,
you'd have to either load them all and waste a lot of memory or make
bytecode caches implement pseudo-filesystem layer on top of it to do it
efficiently. And then there are applications that actually use paths and
FILE and whatnot.

the cache anyway. Thus, I see no serious performance impact even if you
run software from phar, at least when using a bytecode cache.

Besides performance impact, there's manageability impact. Think of how
easy is to work with compiled code as opposed to dynamic language code.

Then, for installation, what other format would you suggest?

For installation - format compatible with existing tools (as most of the
vendors already do). For runtime - I don't think running PHP out of the
single huge file is a very good idea whatever the format is.

I think one advantage of phar is that it is backed by PEAR tools that

I think it's a disadvantage. With all due respect to the PEAR team and
the tools, nobody in the world but PEAR team knows what this format is,
and there's tens of years of tools to work with other formats, supported
by all OSes and languages in existence. I know it works well in all ten
use cases that was considered, but once we recommend it to the wide
world, there would be thousands of cases it doesn't work. Unix was built
on the principle of interoperability, and inventing private formats not
supported by anything violates this principle.

one can expect every PHP developer to have on his system. It would be a
good time now to provide some kind of de-facto-standard for deployment
of PHP code, and phar is the best candidate I know for this.

I'd say the only one - and I don't think making decision about standard
from this position - "we never though of anything better and it just
grew as it is so we make it standard" is a good approach. It works for
the thing is was built for - distributing PEAR files - but when we
talking about PHP-wide policy I don't think we should recommend people
running their applications out of phar files.

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/

18 years ago by Marcus Boerger — view source

unread

Hello Stanislav,

Monday, May 7, 2007, 11:50:15 AM, you wrote:

I think one advantage of phar is that it is backed by PEAR tools that

I think it's a disadvantage.

So you would like to drop PEAR?

....distributing PEAR files - but when we
talking about PHP-wide policy I don't think we should recommend people
running their applications out of phar files.

We are not speaking of a policy here. We are not Java wherenothing else then
whatever *AR's work. Weare PHP and give options. And we try to make it as
easy as possible. Here is something that would make a lot of peoples stuff
way easier. Because believe it or not a bunch ofpeople use PEAR.

Best regards,
Marcus

18 years ago by Ilia Alshanetsky — view source

unread

Because believe it or not a bunch ofpeople use PEAR.

Scary, ain't it? ;-)

Ilia Alshanetsky

18 years ago by David Coallier — view source

unread

Because believe it or not a bunch ofpeople use PEAR.

Scary, ain't it? ;-)

Totally other discussion, but I don't think it's scary, we are pushing
for much more solid packages and more secure applications. (Good QA,
Good work actually done) PEAR does have some pretty ugly packages and
I can't say otherwise, however there's a lot of useful tools and good
developers within pear :)

Ilia Alshanetsky

--

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

18 years ago by Stanislav Malyshev — view source

unread

So you would like to drop PEAR?

Where you get these ideas I wonder? I want to use universally used formats.

We are not speaking of a policy here. We are not Java wherenothing else then

I think we are. Endorsing phar as runtime format is endorsing policy, as
I see it.

whatever *AR's work. Weare PHP and give options. And we try to make it as
easy as possible. Here is something that would make a lot of peoples stuff
way easier. Because believe it or not a bunch of people use PEAR.

All power to them, but why should they use phar as runtime format?

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/

18 years ago by Stanislav Malyshev — view source

unread

Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become pretty useless with the release of PHP6.

We could. But you don't need no extensions for that. If PHP6 makes PEAR
useless, we probably should deal with that problem, shouldn't we?

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/

18 years ago by Gregory Beaver — view source

unread

Stefan Priebsch wrote:

Stanislav Malyshev schrieb:

All power to them, but why should they use phar as runtime format?

Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become pretty useless with the release of PHP6.

Correction: the installation process for PEAR will have to be reverted
to the way it worked in PHP 4. PEAR is unaffected by these changes.
There are other changes that affect PEAR, which is why we are moving all
packages to PHP 5+ currently.

Thanks,
Greg

18 years ago by Gregory Beaver — view source

unread

Stefan Priebsch wrote:

Gregory Beaver schrieb:

Correction: the installation process for PEAR will have to be reverted
to the way it worked in PHP 4. PEAR is unaffected by these changes.

Which, from the end user's viewpoint, makes PEAR useless because they
cannot install PEAR in the first place. That's what I meant.

What? PEAR has been distributed successfully with PHP since version
4.3. From the end user's viewpoint, there is no difference.
go-pear.bat = go-pear.bat on windows, "make install-pear" = "make
install-pear" on unix. The difference is in terms of the maintainers of
PEAR, who will have to do a lot more work in order to synchronize new
releases of PEAR than we do now.

There are other changes that affect PEAR, which is why we are moving all
packages to PHP 5+ currently.

Could you please elaborate on that a little more?
Not in this mailing list please. You are welcome to search the archives
of pear-core and pear-dev, there has been a lot of discussion of PHP 5
and PEAR.

Greg

17 years ago by Milan Babuskov — view source

unread

Rob Richards wrote:

Moving this to the windows list.

I'm having problems to post on it. Care to forward?

Make sure you are using the Visual Studio command prompt as it will
setup your env for you (all the paths, etc...).

I am. As I wrote, I can compile wxWidgets and FlameRobin without any
problems. Maybe I was not clear enough:

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

I do not have mc.exe on my system. I did search on the hard disk to make
sure.

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?

This is the question I'd really like to have an answer to. Not some
'usual' answer from the FAQ. Is the person that wrote/maintains
configure.js script available for contact on this list?

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.

Thanks,

--
Milan Babuskov
http://home.gna.org/vodovod

17 years ago by Milan Babuskov — view source

unread

Rob Richards wrote:

Moving this to the windows list.

I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:

http://www.php.net/mailing-lists.php

Is there a way to contact someone to add it?

Thanks,

--
Milan Babuskov
http://home.gna.org/vodovod

17 years ago by Ryan Panning — view source

unread

Milan Babuskov wrote:

Rob Richards wrote:

Moving this to the windows list.

I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:

http://www.php.net/mailing-lists.php

Is there a way to contact someone to add it?

Thanks,

Are you looking for this?
http://news.php.net/

17 years ago by Lester Caine — view source

unread

Ryan Panning wrote:

Milan Babuskov wrote:

Rob Richards wrote:

Moving this to the windows list.

I'm having problems to post on it via newsgroup interface, and I don't
know how to subscribe to the mailing list, since it is not listed here:

http://www.php.net/mailing-lists.php

Is there a way to contact someone to add it?

Thanks,

Are you looking for this?
http://news.php.net/

Not a lot of use as it does not give details of how to JOIN php.internals.win
which is where Milan has been directed.
Milan - bare in mind that the remaining bug listed for php_interbase is
actually a linux one rather than windows, and most of the stuff currently
being asked for has to be done on the raw code, so compiling also in windows
comes later - since I know you are happier in linux anyway - just like I am in
BORLAND windows land ;)

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

17 years ago by Pierre Joye — view source

unread

Hi Lester, Milan,

Not a lot of use as it does not give details of how to JOIN
php.internals.win

I sent the email to subscribe, but the commands are the same for all php lists:
<list-name>-subscribe@lists.php.net

or

<list-name>-help@lists.php.net to get a list of commands (afair :)

which is where Milan has been directed.
Milan - bare in mind that the remaining bug listed for php_interbase is
actually a linux one rather than windows, and most of the stuff currently
being asked for has to be done on the raw code, so compiling also in windows
comes later - since I know you are happier in linux anyway - just like I am
in BORLAND windows land ;)

Yes :) The primary goal is to get bug(s) fixed, code reviewed and the
windows binaries tested. If you can also help to build the libraries
on Windows then even better, but it is not a requirement (now or
later).

Thanks both for your efforts :)

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org

17 years ago by Lester Caine — view source

unread

Pierre Joye wrote:

Hi Lester, Milan,

Not a lot of use as it does not give details of how to JOIN
php.internals.win

I sent the email to subscribe, but the commands are the same for all php lists:
<list-name>-subscribe@lists.php.net

<list-name>-help@lists.php.net to get a list of commands (afair :)

Just to clarify here since <list-name> is a little confusing.
The list we are talking about is 'internals.win' when used with lists.php.net
and not 'php.internals.win' as used in news.php.net or 'php-internals.win' as
suggested by http://www.php.net/mailing-lists.php ( bottom -
php-whatever-help@lists.php.net )

I only comment because it took me a while to work out the correct path - since
I had used http://www.php.net/mailing-lists.php to access internals.

To tidy things up, it would be nice to see internals.win on the Internals
Mailing Lists section ;)

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

17 years ago by Milan Babuskov — view source

unread

Ryan Panning wrote:

Are you looking for this?
http://news.php.net/

Been there. Don't see any way to subscribe to internals-win, so I can
post to it. Or am I missing something?

Thanks,

--
Milan Babuskov
http://www.guacosoft.com

[RFC] Starting 5.3

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.

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?

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?

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.

Right, but php and PEAR are required to read/create/inspect the archive.

That's the question - if phar is not to be recommended in production as deployment format, it belongs to PECL.

We don't need phar extension in the core to make phar installer, as far as I understand.

I thought this was officially declared non-argument in scope of PHP discussions? ;)

Because it's a bad idea. And nobody disallowing that - we just refrain from promoting it.

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.

There would be no safety and no prevention, just plugging one way of thousands. IMHO it is pointless.

Not breaking streams in php 6?

Meaning a lot of people are running apps packaged in phar's? Could you bring forward some examples?

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers,

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.

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

All power to them, but why should they use phar as runtime format?

We could. But you don't need no extensions for that. If PHP6 makes PEAR useless, we probably should deal with that problem, shouldn't we?

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

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.

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?

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?

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.

That's the question - if phar is not to be recommended in production as
deployment format, it belongs to PECL.

We don't need phar extension in the core to make phar installer, as far
as I understand.

I thought this was officially declared non-argument in scope of PHP
discussions? ;)

Because it's a bad idea. And nobody disallowing that - we just refrain
from promoting it.

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.

There would be no safety and no prevention, just plugging one way of
thousands. IMHO it is pointless.

Meaning a lot of people are running apps packaged in phar's? Could you
bring forward some examples?

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

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.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

We could. But you don't need no extensions for that. If PHP6 makes PEAR
useless, we probably should deal with that problem, shouldn't we?

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL