The PHP development team would like to announce the immediate
availability of PHP 5.2.2 and availability of PHP 4.4.7. These releases
are major stability and security enhancements of the 5.x and 4.4.x
branches, and all users are strongly encouraged to upgrade to it as soon
as possible.
Hey! It wasn't THAT scary! Just a table which has the most recent
activity on the left side columns.
Not too wide.
Easy to see which version and the either source or Win32 stuff.
And also all the additional files requested.
I like the idea. My implementation though. Hmmm. Ok. I agree.
Eeek!
To commit in cvs a Pear package that already approved by the Pear group.
(PHP_Debug)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Would you be willing to produce the HTML needed for the redesign?
Unfortunately my knowledge about HTML and CSS is very limited, so I
don't think the page would look very good in case I did it. I would
prefer if somebody with more knowledge could do it.
I'd be able to do the HTML and CSS on
Hi,
I contacted Stig Venaas who is listed in the php/EXTENSIONS file as
being the maintainer of the LDAP extension. I have some patches I would
like to provide/apply
so that the extension supports LDAP + TLS a little better. Currently
there is no way to deal with certificates programatically,
On 05/04/2007 01:17 PM, Conrad Vermeulen wrote:
Hi,
I contacted Stig Venaas who is listed in the php/EXTENSIONS file as
being the maintainer of the LDAP extension. I have some patches I would
like to provide/apply
so that the extension supports LDAP + TLS a little better. Currently
there is
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:
1) Adding PECL/Phar as default extension
2) Add open_filename debug info to streams
3) Add
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
On 05/04/2007 07:07 PM, 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.
I'd like to wait for the end of the year (i.e. for the end of PHP4 support
period) and then branch
On 4-May-07, at 11:07 AM, 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:
1) Adding PECL/Phar as default
Hello Ilia,
Friday, May 4, 2007, 6:54:33 PM, you wrote:
On 4-May-07, at 11:07 AM, 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
On 05/04/2007 09:32 PM, Marcus Boerger wrote:
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
On 4-May-07, at 1:32 PM, Marcus Boerger wrote:
\For the biggest changes i'd like to see the following:
1) 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.
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
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.
On 4-May-07, at 1:49 PM, Edin Kadribasic wrote:
Antony Dovgal wrote:
What's the problem with
On 05/04/2007 09:49 PM, 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
Antony Dovgal wrote:
On 05/04/2007 09:49 PM, 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
On 05/04/2007 10:06 PM, Edin Kadribasic wrote:
Antony Dovgal wrote:
On 05/04/2007 09:49 PM, 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`.
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
On 05/04/2007 10:16 PM, Edin Kadribasic wrote:
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
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
On Fri, May 4, 2007 1:09 pm, Antony Dovgal 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
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith 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
On Fri, May 4, 2007 4:49 am, Richard Quadling wrote:
Hey! It wasn't THAT scary! Just a table which has the most recent
activity on the left side columns.
Not too wide.
Easy to see which version and the either source or Win32 stuff.
And also all the additional files requested.
I like the
Hello Ilia,
Friday, May 4, 2007, 9:24:08 PM, you wrote:
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith 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
On Fri, May 4, 2007 12:46 pm, Ilia Alshanetsky wrote:
2) 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
On 05/04/2007 11:22 PM, Richard Lynch wrote:
On Fri, May 4, 2007 1:09 pm, Antony Dovgal 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
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
Ilia Alshanetsky wrote:
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith 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
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
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
--
PHP Internals - PHP
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
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
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
- 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
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
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:[EMAIL
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
I believe this is a bug in PHP 5.2.2. I've tried to report this for PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't following
the proper procedures ...
Anyway, as I wrote before[1], raw POST data isn't making it through in
PHP 5.2.2 which results in XML-RPC communications to
Is your always_populate_raw_post_data enabled? Also, have you tried
accessing the data from php://input ?
On 4-May-07, at 4:18 PM, Dirk Haun wrote:
I believe this is a bug in PHP 5.2.2. I've tried to report this for
PHP
5.2.2RC2 but apparently wasn't making myself clear or wasn't
Ilia Alshanetsky wrote:
Is your always_populate_raw_post_data enabled?
Yes:
; Always populate the $HTTP_RAW_POST_DATA variable.
always_populate_raw_post_data = On
As I already said: On or Off doesn't seem to make a difference.
Also, have you tried
accessing the data from php://input ?
I
Hi,
Ilia Alshanetsky wrote:
I am going to finalize the patch and add it to 5.2.2 in the coming weeks.
Ilia
There is no trace of such patch in PHP 5.2.2 changelog.
Any news on it? Thanks.
Mathieu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
42 matches
Mail list logo
