On Mon, 7 May 2007, Stanislav Malyshev wrote:
> > 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 wron
On Mon, 7 May 2007, Stanislav Malyshev 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 P
I'm a PHP Programmer from China, I'd like to help translate phpdoc_zh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
> Stanislav Malyshev wrote:
> > > can write this data to disk. So, you needs 20MB. If serialize (and of
> > > course unserialize) would be able to write directly to disk (or read
> > > directly from disk), you only needs 10MB.
> >
> > Actually having s
Ditto Richard's comments about false-implications of security, but I'd
also like to add that *IF* folks decide on the whole that this is worth
adding, it should be done more generically than a setting for md5 and a
setting for sha1.
e.g.
or
or
or whatever hash algo you're looking for. Th
Hello,
I am getting a SIGSEGV when compiling php-5.2.2.
gdb breaks up at the if statement of the following function
static void php_apache_add_version(apr_pool_t *p)
{
TSRMLS_FETCH();
if (PG(expose_php)) {
ap_add_version_component(p, "PHP/" PHP_VERSION);
}
Gregory Beaver wrote:
[snip]
> megabytes of information just to locate a file. The zip file format has
> the same limitation - the entire archive needs to be scanned.
>
> Both of these formats were not designed for random access in the way a
> traditional filesystem is designed. In fact, I could
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having serialize/unserialize be able to write directly to a
stream and read d
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 instal
On Mon, May 7, 2007 1:17 am, 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.
+1
If there has to be a 5.3, I'd want to see features that:
are inc
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having serialize/unserialize be able to write directly to a
stream and read directly from a stream might
On Mon, May 7, 2007 2:30 pm, Dirk Haun wrote:
> Ilia Alshanetsky wrote:
>>I sure hope those nifty Web 2.0 sites don't use SOAP and XML-RPC but
>>rather JSON or REST.
>
> Okay, but XML-RPC is used for Pingbacks, Trackbacks, and for pinging
> weblog directories like Technorati. That's something like
What purpose does this serve, exactly?...
Seems like anybody who can intercept the upload and send bad file data
can also send a matching MD5 for the bad data...
Actually, re-reading the message clarified for me that you're doing
this only to save the time of whatever it would take to do an MD5 f
Ilia Alshanetsky wrote:
>
> On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:
>
>> I must have missed something. Did you change the documented behaviour
>> that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP encounters an
>> unknown content type? If so, that was most definitely not a bug and
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
On 7-May-07, at 4:00 PM, Rasmus Lerdorf wrote:
I must have missed something. Did you change the documented behaviour
that $_SERVER['HTTP_RAW_POST_DATA'] is populated when PHP
encounters an
unknown content type? If so, that was most definitely not a bug
and not
something that should have
Ilia Alshanetsky wrote:
>
> On 7-May-07, at 2:35 PM, Dirk Haun wrote:
>
>> David Coallier wrote:
>>
>>> Anyone has an answer/tests to that bug* so we can stop this
>>> discussion ? :)
>>
>> The bug has apparently been fixed in CVS. Haven't had a chance to test
>> it, but will do as soon as possib
Ilia Alshanetsky wrote:
>> The bug has apparently been fixed in CVS. Haven't had a chance to test
>> it, but will do as soon as possible.
>
>Please let me know how it works out.
I've tested php5.2-200705071830.tar.gz from snaps.php.net and the bug
seems to be fixed. Thanks.
>One interesting fea
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
On 7-May-07, at 2:35 PM, Dirk Haun wrote:
David Coallier wrote:
Anyone has an answer/tests to that bug* so we can stop this
discussion ? :)
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Please let me know how it works out. One
The stub could also easily include code to allow for an extraction flag
to work. So you could run php my.phar --extract and have the code dumped
to the FS as it originally was.
The choice to add these things (the stub and the extract flag), is just
that, a choice. The same as choosing short tag
On 5/7/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 05/07/2007 10:39 PM, Stanislav Malyshev wrote:
>> 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 fut
On 05/07/2007 10:39 PM, Stanislav Malyshev wrote:
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.
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 wh
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 mean
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 bec
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
Hi,
There has been a bit of inevitable FUD with phar. Although the manual
(http://php.net/phar) describes a fair amount of how phar works, the
design decisions are not documented.
Originally, the phar stream wrapper was a userspace thing. Davey Shafik
designed it to take advantage of a neat loo
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:
1. phar needs script-defined named stream
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 releas
David Coallier wrote:
> Anyone has an answer/tests to that bug* so we can stop this discussion ? :)
The bug has apparently been fixed in CVS. Haven't had a chance to test
it, but will do as soon as possible.
Now the question is: When can we expect an update? I see people talking
about what shoul
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
[EMAIL PROTECTED] http://www.zend.co
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.
On 5/7/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 7-May-07, at 2:24 PM, Marcus Boerger wrote:
> 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 sec
On 7-May-07, at 2:24 PM, Marcus Boerger wrote:
Because believe it or not a bunch ofpeople use PEAR.
Scary, ain't it? ;-)
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 sho
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 i
Antony Dovgal wrote:
> On 05/07/2007 04:18 PM, Lukas Kahwe Smith 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. Prov
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
>>> abili
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 t
On 5/7/07, Unknown W. Brackets <[EMAIL PROTECTED]> wrote:
Really? I've used this pseudonym for years and years, dozens and dozens
of places. I've got a patch checked into Mozilla using it. I've
communicated with other developers in a wide variety of places...
I cannot recall anyone saying it
Mike Robinson wrote:
It could well be the last chance to get the mail() logger into 5.x as well,
and IMHO a lot of
people are waiting for this that can't/won't migrate to PHP6 quickly.
i have added it to the open discussion items for 5.2.3:
http://oss.backendmedia.com/PhP52
regards,
Lukas
--
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 b
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 us
Really? I've used this pseudonym for years and years, dozens and dozens
of places. I've got a patch checked into Mozilla using it. I've
communicated with other developers in a wide variety of places...
I cannot recall anyone saying it was rude of me to use such a name. In
fact, most people
Antony Dovgal wrote:
On 05/07/2007 04:18 PM, Lukas Kahwe Smith 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 interna
On Mon, 7 May 2007, Antony Dovgal wrote:
> On 05/06/2007 10:11 PM, 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.
>
> Tha
On Mon, 7 May 2007, 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
On Sun, 6 May 2007, Lukas Kahwe Smith wrote:
> 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
On 05/07/2007 04:18 PM, Lukas Kahwe Smith 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
On Sun, 6 May 2007, Mike Robinson wrote:
> It could well be the last chance to get the mail() logger into 5.x as well,
> and IMHO a lot of
> people are waiting for this that can't/won't migrate to PHP6 quickly.
There is no reason why that can't go into PHP 5.2.3.
regards,
Derick
--
Derick Ret
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 o
On Fri, 4 May 2007, Lukas Kahwe Smith wrote:
> 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
> > > sy
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 awa
Hi,
I'm submitting a patch to perform "on the fly" MD5/SHA1 digest
calculation of a file uploaded via the HTTP POST method. Being
not uncommon for applications to require some digest of a freshly
uploaded file, doing the math directly in the buffer where the file is
being read can save some tim
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
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (42 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Verified parse error loadin
Lester Caine schrieb:
> 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 allo
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (631 total including feature requests)
===[*Directory/Filesystem functions]
40661 Open cwd is reset when shutdown handler runs
===
On Sun, 6 May 2007, Unknown W. Brackets wrote:
> Sorry, I apologize. Although you were curt I should not have been so in
> reply.
>
> I used to manage development of a reasonably popular open source project, and
> if one of our developers had ever said something like that, it would have
> greatl
Hi Stefan,
On 5/7/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
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 wi
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
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
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 o
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
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
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 sur
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
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 woul
Hello steve,
why don't you give it a try:
http://de.php.net/phar
http://pecl.php.net/package/phar
marcus
Monday, May 7, 2007, 4:55:10 AM, you wrote:
> Before reading the thread on the idea of a PHP 5.3 branch, I had never
> heard of phar, so please excuse my neophyte questions, but I couldn't
70 matches
Mail list logo
