Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:
http://php.net/~derick/meeting-notes.html
regards,
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello all,
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was THE EXACT SAME ONE that my patch uses.
To add insult to injury, it's mentioned that Marcus was going to provide
a patch (my problem is not with Marcus, in fact, he was very supportive
and helpful when I was writing the patch and the __autoload mechanism
I'm using is thanks to his input. My problem is that my patch was
completely ignored and someone else was assigned to write a patch, when
the one I already wrote can be used).
My patch meets all the requirements, except for the following items:
-
"The suggested separator is "" as this is the only free choice." - I
currently use the ':' separator, but this can be easily changed. -
"Functions in name spaces are allowed." - I added this once and
posted the patch to the list, but many (including Andi himself) agreed
that we should just stick to classes inside namespaces. The only thing I
accomplished was having the function be used as
namespace_name:my_function. If a namespace import for functions were to
work, then an __autoload for functions would need to be supported in the
engine. This has been suggested before, as having a global __call
function. With a global __call function, namespace imports can also
import functions. -
"Constants in name spaces are allowed unless we find problems with
the implementation." - I have not tried this, but if all agree, I can
check to see how easy it would be to add this to my patch.
The attached patch is identical to what I had since August 9th, but was
updated to apply cleanly to the latest PHP 5.1 CVS version (it must be
applied before running buildconf).
I do not mean to offend anyone or point fingers, and I am sorry if my
tone is a bit harsh, but please understand that I have reason to have
felt ignored in this whole manner. If you need more information about
the "inner workings of my patch", then please email me or post your
questions to the list, and I'll be more than happy to explain.
Regards,
Jessie Hernandez
Derick Rethans wrote:
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:http://php.net/~derick/meeting-notes.html
regards,
Derick
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the approach
that was agreed on was THE EXACT SAME ONE that my patch uses. To add insult
to injury, it's mentioned that Marcus was going to provide a patch (my problem
is not with Marcus, in fact, he was very supportive and helpful when I was
writing the patch and the __autoload mechanism I'm using is thanks to his
input. My problem is that my patch was completely ignored and someone else was
assigned to write a patch, when the one I already wrote can be used).
Hang on a bit, if it's assigned to Marcus, doesn't mean he can not work
with you on that.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Derick,
Tuesday, November 22, 2005, 7:26:56 PM, you wrote:
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the approach
that was agreed on was THE EXACT SAME ONE that my patch uses. To add insult
to injury, it's mentioned that Marcus was going to provide a patch (my problem
is not with Marcus, in fact, he was very supportive and helpful when I was
writing the patch and the __autoload mechanism I'm using is thanks to his
input. My problem is that my patch was completely ignored and someone else was
assigned to write a patch, when the one I already wrote can be used).
Hang on a bit, if it's assigned to Marcus, doesn't mean he can not work
with you on that.
Despite the written sentence i had namespaces on my radar for a long time
now. That i didn't do anything just reflects the current state of PHP. We
are not going to have namespaces for a list of good reasons. Your patch
and the amount of people asking for that feature started discussions all
over again. So while beeing in paris we were able to look at the following
things the stuff we knew your patch was supposed to do and the stuff we
wanted your patch to do as well as the module patch and the stuff we thought
that patch should do. After a long discussion we came to the intermediate
conclusion that it is worth to restart working on namespaces again since a
few issues we had with the first approach have been solved as of now.
However the notes show that PHP will undergo a big amount of changes
especially engine api wise. Thus i guess we won't start working on that
beforehand. If you feel to do more work on your stuff then go ahead we
might go with exactly your patch or ignore it completley when the changes
are done. That's how PHP is done and has nothing to do whetehr i plan to do
some work on my own. Indeed i could come up with a patch that would be
outrules by yours or somebody elses as well. That's open source. Things
might be ignored or removed or rewritten at any time by others. The
advantage is that we can all work together if we feel like and that by doing
so we cannot only learn from each other but reach a very good final result
(if there is such a thing as final result in software).
To cut this short. As soon as i feel like i will start to do some work. And
as soon as there is something to show i will post it. Since i always showed
my stuff were early here. Should you do something earlier i think i will try
to catch up with you and either say nothing to do for me left or send you my
thoughts by mail or try to come up with my brand own ideas.
We'll see, nothing has been made a law by those notes.
marcus
Marcus,
I agree that we should work together on this, so that we can achieve the
best result possible and to avoid duplicate work. To a certain degree,
we have already worked together on this, when you suggested using the
__autoload mechanism to resolve namespace imports and this is what I
ended up doing.
I will try to add functions and constants soon to the patch, and will
look at the PHP 6 source to see what I need to do to make it work with
that version.
Regards,
Jessie
Marcus Boerger wrote:
Despite the written sentence i had namespaces on my radar for a long time
now. That i didn't do anything just reflects the current state of PHP. We
are not going to have namespaces for a list of good reasons. Your patch
and the amount of people asking for that feature started discussions all
over again. So while beeing in paris we were able to look at the following
things the stuff we knew your patch was supposed to do and the stuff we
wanted your patch to do as well as the module patch and the stuff we thought
that patch should do. After a long discussion we came to the intermediate
conclusion that it is worth to restart working on namespaces again since a
few issues we had with the first approach have been solved as of now.
However the notes show that PHP will undergo a big amount of changes
especially engine api wise. Thus i guess we won't start working on that
beforehand. If you feel to do more work on your stuff then go ahead we
might go with exactly your patch or ignore it completley when the changes
are done. That's how PHP is done and has nothing to do whetehr i plan to do
some work on my own. Indeed i could come up with a patch that would be
outrules by yours or somebody elses as well. That's open source. Things
might be ignored or removed or rewritten at any time by others. The
advantage is that we can all work together if we feel like and that by doing
so we cannot only learn from each other but reach a very good final result
(if there is such a thing as final result in software).To cut this short. As soon as i feel like i will start to do some work. And
as soon as there is something to show i will post it. Since i always showed
my stuff were early here. Should you do something earlier i think i will try
to catch up with you and either say nothing to do for me left or send you my
thoughts by mail or try to come up with my brand own ideas.We'll see, nothing has been made a law by those notes.
marcus
Jessie Hernandez wrote:
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was THE EXACT SAME ONE that my patch uses.
To add insult to injury, it's mentioned that Marcus was going to provide
a patch (my problem is not with Marcus, in fact, he was very supportive
and helpful when I was writing the patch and the __autoload mechanism
I'm using is thanks to his input. My problem is that my patch was
completely ignored and someone else was assigned to write a patch, when
the one I already wrote can be used).
How in the world do you know your patch was ignored? It wasn't. But it
also isn't going to work as-is, especially in the new Unicode world, so
it is going to take more than one person to play with it and see what
can be done. Marcus simply volunteered to do that.
-Rasmus
Hi Rasmus,
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:
"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Then we saw an alternative implementation of name spaces with
"Modules"".
Anyways, from what you said, is namespace support only going to be added
in PHP 6? I have been basing my patch on 5.1, hoping that it would make
it before 6, as the patch is small and has absolutely no BC problems.
Obviously, I don't agree on having to wait that long, but if that is the
case, I'll check what changes I need to do in order to apply it to PHP
- Thanks for the clarification.
Regards,
Jessie Hernandez
Rasmus Lerdorf wrote:
Jessie Hernandez wrote:
I saw the notes regarding namespaces, and it really suprised me that
the namespace patch was not looked at in detail, discarded, and then
the approach that was agreed on was THE EXACT SAME ONE that my patch
uses. To add insult to injury, it's mentioned that Marcus was going to
provide a patch (my problem is not with Marcus, in fact, he was very
supportive and helpful when I was writing the patch and the __autoload
mechanism I'm using is thanks to his input. My problem is that my
patch was completely ignored and someone else was assigned to write a
patch, when the one I already wrote can be used).How in the world do you know your patch was ignored? It wasn't. But it
also isn't going to work as-is, especially in the new Unicode world, so
it is going to take more than one person to play with it and see what
can be done. Marcus simply volunteered to do that.-Rasmus
Jessie Hernandez wrote:
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Then we saw an alternative implementation of name spaces with
"Modules"".
Yes, Dmitry has a module-based namespace patch as well. Yours isn't
actually the only working patch on the table right now and as the notes
say, we looked at it.
Anyways, from what you said, is namespace support only going to be added
in PHP 6? I have been basing my patch on 5.1, hoping that it would make
it before 6, as the patch is small and has absolutely no BC problems.
The entire meeting was exclusively about PHP 6. We are too far along in
the 5.1 process to make any large changes at this point.
-Rasmus
Rasmus Lerdorf wrote:
The entire meeting was exclusively about PHP 6. We are too far along in
the 5.1 process to make any large changes at this point.
Actually, I did not mean to include it in the current 5.1 version (as
that's about to be released), but I was hoping for it to make it in a
5.2 release, for example. Or will there be no more minor releases until 6?
Regards,
Jessie Hernandez
Hello Jessie,
Tuesday, November 22, 2005, 7:57:47 PM, you wrote:
Rasmus Lerdorf wrote:
The entire meeting was exclusively about PHP 6. We are too far along in
the 5.1 process to make any large changes at this point.
Actually, I did not mean to include it in the current 5.1 version (as
that's about to be released), but I was hoping for it to make it in a
5.2 release, for example. Or will there be no more minor releases until 6?
There was no decison on that yet. Actually there was no real discussion on
that issue anyway. PHP is developed in a way that those decisions are done
when they are at hand. That said we are all working on getting 5.1 out of
the doors. Ass soon as we have done that there will be a bunch of MFHing
from head to 5.1.1-dev. Then there will be 5.1.1 and then..well i cannot
look deeper in my glass ball. It doesn't show anything more.
marcus
I think that automatic __toString calling for (string)$obj,
$obj.'somestring' and so on is urgent compared to other features and
should be available in 5.1.1 or at latest - 5.2.0. I suppose that
"object #XX" is not useful for anyone programming in PHP.
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:http://php.net/~derick/meeting-notes.html
regards,
DerickDerick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:http://php.net/~derick/meeting-notes.html
regards,
Derick
Hello,
what was the reason for the decision to drop asp tags? We are using
them in our templates because of the <%= shortcut and no conflicts
with X(HT)ML.
Regards,
Stefan
Hello Stefan,
"<%=" is of course also conflicting the XML specs since "<"
must be followed by a "!" is we are in a DTD context. Or a "?"
to start a processing instruction or a valid element name. And
"%" cannot start an element name.
marcus
Wednesday, November 23, 2005, 5:07:22 PM, you wrote:
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:http://php.net/~derick/meeting-notes.html
regards,
Derick
Hello,
what was the reason for the decision to drop asp tags? We are using
them in our templates because of the <%= shortcut and no conflicts
with X(HT)ML.
Regards,
Stefan
--
Best regards,
Marcus
Marcus Boerger wrote:
Hello Stefan,
"<%=" is of course also conflicting the XML specs since "<"
must be followed by a "!" is we are in a DTD context. Or a "?"
to start a processing instruction or a valid element name. And
"%" cannot start an element name.
When we are talking about asp tags we are talking about the ability of
PHP to parse xml documents, say in order to produce valid xhtml. PHP
will produce parse error if you have short tags enabled when trying to
parse xml, while with short tags disabled and asp tags enabled it parses
them just fine which makes it sweet for making templating of xml documents.
I really see no reason to remove a feature that at least some people
find useful, and which has no effects on those that do not have it enabled.
Edin
Marcus Boerger wrote:
Hello Stefan,
"<%=" is of course also conflicting the XML specs since "<"
must be followed by a "!" is we are in a DTD context. Or a "?"
to start a processing instruction or a valid element name. And
"%" cannot start an element name.When we are talking about asp tags we are talking about the ability of
PHP to parse xml documents, say in order to produce valid xhtml. PHP
will produce parse error if you have short tags enabled when trying to
parse xml, while with short tags disabled and asp tags enabled it parses
them just fine which makes it sweet for making templating of xml documents.I really see no reason to remove a feature that at least some people
find useful, and which has no effects on those that do not have it enabled.Edin
Exactly. PHP chokes on <?xml if short tags are enabled.
Regards,
Stefan
Exactly. PHP chokes on <?xml if short tags are enabled.
And just because of that we're removing those too. >:)
--Jani
Hi Edin, et al:
PHP
will produce parse error if you have short tags enabled when trying to
parse xml, while with short tags disabled and asp tags enabled it parses
them just fine which makes it sweet for making templating of xml documents.
How PHP chokes on <?xml tags when short tags is enabled is compleltely
silly. There's a patch here to fix it,
http://news.php.net/php.internals/18493, some proof of why it's a problem,
http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
report, http://bugs.php.net/bug.php?id=25987.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
How PHP chokes on <?xml tags when short tags is enabled is compleltely
silly. There's a patch here to fix it,
http://news.php.net/php.internals/18493, some proof of why it's a problem,
http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
report, http://bugs.php.net/bug.php?id=25987.
As the author of the patch you mentioned, I should reitterate that I don't
think that it's a good fix. Treating <?xml as special is a hack, not a
broadband solution.
-Sara
Hello Sara,
Sunday, November 27, 2005, 3:39:40 AM, you wrote:
How PHP chokes on <?xml tags when short tags is enabled is compleltely
silly. There's a patch here to fix it,
http://news.php.net/php.internals/18493, some proof of why it's a problem,
http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
report, http://bugs.php.net/bug.php?id=25987.As the author of the patch you mentioned, I should reitterate that I don't
think that it's a good fix. Treating <?xml as special is a hack, not a
broadband solution.
To second this, the xml standard allows any name after '<?' as processing
instruction. Widely in use is for example '<?jsp' and do you want to start
special treatment for java stuff in PHP? ;-)
Best regards,
Marcus
Hi Marcus:
To second this, the xml standard allows any name after '<?' as processing
instruction. Widely in use is for example '<?jsp' and do you want to start
special treatment for java stuff in PHP? ;-)
First, PHP scripts are not XML files, so why are we concerned with what
the XML standard says?
Second, PHP is frequently used to output XML files, necessitating such PHP
scripts contain the string "<?xml" in them. But in order to ensure
scripts work when short tags is on, one must write something contorted
like:
echo '<' . '?xml ...';
Third, if someone wrote a script using "<?xml" with short tags off instead
of the above, PHP needlessly fails if short tags is on, eliminating
portability.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi,
First, PHP scripts are not XML files, so why are we concerned with what
the XML standard says?
It isn't about the XML standard but about exceptions for the PHP parser and
why should <?xml be treated different from <?jsp or <?xsl or <?foo or ...
which all are used (hm, not sure about <?foo) and sometimes even in
combination with PHP.
Second, PHP is frequently used to output XML files, necessitating such PHP
scripts contain the string "<?xml" in them. But in order to ensure
scripts work when short tags is on, one must write something contorted
like:echo '<' . '?xml ...';
echo '<?xml ...';
just works fine.
Third, if someone wrote a script using "<?xml" with short tags off instead
of the above, PHP needlessly fails if short tags is on, eliminating
portability.
so just remove short_tags :-)
johannes
It isn't about the XML standard but about exceptions for the PHP parser and
why should <?xml be treated different from <?jsp or <?xsl or <?foo or ...
which all are used (hm, not sure about <?foo) and sometimes even in
combination with PHP.
I recall this being discussed before, but not what came of it: is there
a problem with just ignoring <?foo where foo is anything other than php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.
I recall this being discussed before, but not what came of it: is there
a problem with just ignoring <?foo where foo is anything other than php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.
The problem there becomes legacy support for:
<?foo();?>
And before you say "just watch for parens" there's also:
<?foo::bar();?>
and a much more insiduous example:
<?die ?>
no semicolon, no parens, no paamayim nekudotayim, nothing but a perfectly
valid looking PI tag.
-Sara
What concerns me most is that <?php= does not work, regardless if short
tags will be disabled or not in php6. I currently use <%= to counter
this, but I am most certainly not happy with it.
So a clean <?php= solution would be ideal, so I wouldn't have to care
about xml/xsl files parsed and neither about my templates growing too
large because of php overhead.
Sara Golemon wrote:
I recall this being discussed before, but not what came of it: is there
a problem with just ignoring <?foo where foo is anything other than php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.The problem there becomes legacy support for:
<?foo();?>
And before you say "just watch for parens" there's also:
<?foo::bar();?>
and a much more insiduous example:
<?die ?>
no semicolon, no parens, no paamayim nekudotayim, nothing but a
perfectly valid looking PI tag.-Sara
Hello Bastian,
id like to see '<?php=' too.
marcus
Monday, November 28, 2005, 9:56:56 AM, you wrote:
What concerns me most is that <?php= does not work, regardless if short
tags will be disabled or not in php6. I currently use <%= to counter
this, but I am most certainly not happy with it.
So a clean <?php= solution would be ideal, so I wouldn't have to care
about xml/xsl files parsed and neither about my templates growing too
large because of php overhead.
Sara Golemon wrote:
I recall this being discussed before, but not what came of it: is there
a problem with just ignoring <?foo where foo is anything other than php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.The problem there becomes legacy support for:
<?foo();?>
And before you say "just watch for parens" there's also:
<?foo::bar();?>
and a much more insiduous example:
<?die ?>
no semicolon, no parens, no paamayim nekudotayim, nothing but a
perfectly valid looking PI tag.-Sara
Best regards,
Marcus
me too, i've asked for this before but i remember it being laughed away...
ron
"Marcus Boerger" helly@php.net wrote in message
news:793837231.20051128202942@marcus-boerger.de...
Hello Bastian,
id like to see '<?php=' too.
marcus
Monday, November 28, 2005, 9:56:56 AM, you wrote:
What concerns me most is that <?php= does not work, regardless if short
tags will be disabled or not in php6. I currently use <%= to counter
this, but I am most certainly not happy with it.So a clean <?php= solution would be ideal, so I wouldn't have to care
about xml/xsl files parsed and neither about my templates growing too
large because of php overhead.Sara Golemon wrote:
I recall this being discussed before, but not what came of it: is
there
a problem with just ignoring <?foo where foo is anything other than
php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.The problem there becomes legacy support for:
<?foo();?>
And before you say "just watch for parens" there's also:
<?foo::bar();?>
and a much more insiduous example:
<?die ?>
no semicolon, no parens, no paamayim nekudotayim, nothing but a
perfectly valid looking PI tag.-Sara
Best regards,
Marcus
Derick Rethans wrote:
discussing the things we want to do for PHP 6. Partly because of the
The whole list of decisions is very reasonable, congratulations!
My only gripe is about the removal of curly braces for string offsets: I
very much like the way you undeprecated var ('As there is no real reason
why we should remove it, we agreed on simply making "var" an alias to
"public" and removing the warning"') and I think curly braces for string
offsets should be treated the same way.
As far as named parameters go: I can live with the decision as we use
our own patch for that anyway ;-)
- Chris
As far as named parameters go: I can live with the decision as we use
our own patch for that anyway
Christian,
Where are the details on this patch?
Kind Regards,
--
Ian P. Christian ~ http://pookey.co.uk
Derick Rethans wrote:
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:
http://php.net/~derick/meeting-notes.html
I really appreciate your effort in this and offer my feedback:
4.5 Cleanup for {} vs. []
It was already discussed. Many people would be confused from
documentation statement "[] was marked as deprecated in 4.0.6 - 5.1
but then suddenly {} was deprecated instead and removed in 6.0" and
many scripts would refuse to work due to this.
4.9 Make parameter order consistent over all functions
Others talked probably about:
str_replace(needle, replace, haystack) - compare with e.g. SQL
REPLACE(haystack, needle, replace)
ereg(pattern, haystack)
etc. But I am also against changing the parameters order.
4.10 Minor function changes:
microtime()
You showed that the most common usage of this function without
parameters remain working (with E_NOTICE) but what's with other
usages? Gain from this change is really minimal but cause that some
code working in PHP 4 will not work in PHP 6 without ugly hacks.
Jakub Vrana
4.5 Cleanup for {} vs. []
It was already discussed. Many people would be confused from
documentation statement "[] was marked as deprecated in 4.0.6 - 5.1
but then suddenly {} was deprecated instead and removed in 6.0" and
many scripts would refuse to work due to this.
That's why we wanted to add the `E_STRICT` warning about it..
But I'd rather have this whole issue changed back to what
it really was about: separating [] and {} altogether.
We could start with making it an E_ERR..erm..E_STRICT notice
if you use {} with arrays or [] with strings. And really separate
them in PHP 6. But does it make any sense?
Removing {} is ultimately the right thing to do, whatever the
anti-purists may think. "{$str{1}}" vs. "{$str[1]}", you decide..
--Jani
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
derick@php.net (Derick Rethans) wrote:
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:
Very interesting - thanks for the details. It all sounds very
promising.
Regarding safe_mode I agree that I'll never be any kind of magic
wundertool. But as the docs also specify, many shared hosts currently
"rely" on it (meaning they have setups where the users don't have
shell opportunities or other ways of accessing each other's files).
I'm not looking for any near-safe_mode-substitution. I'm more
concerned about the deployment of PHP6 at shared hosts.
Since PHP6 have a bunch of different changes and requires a lot of
information I think there should be put an effort of creating a "best
practices" document for these kind of setups. Something like enabling
open_basedir and disabling exec-functions (popen, exec, shell_exec,
passthru...). Maybe a new setting to disable all of these typies of
functions together - I don't think it is a pretty solution to e.g.
blacklist about six specific functions and hoping that this list is
static.
Furthermore, and just a though: would it be possible to have an option
when compiling an apache module of setting the open_basedir value to
the same as the virtual host's DOCUMENT_ROOT? I think deployment could
be much easier this way.
(oh yeah, and I really hope glob() results would be passed through
open_basedir checks... furthermore I want a pony!)
--
- Peter Brodersen
Peter Brodersen wrote:
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
derick@php.net (Derick Rethans) wrote:On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
placed the notes here:Very interesting - thanks for the details. It all sounds very
promising.Regarding safe_mode I agree that I'll never be any kind of magic
wundertool. But as the docs also specify, many shared hosts currently
"rely" on it (meaning they have setups where the users don't have
shell opportunities or other ways of accessing each other's files).I'm not looking for any near-safe_mode-substitution. I'm more
concerned about the deployment of PHP6 at shared hosts.
These shared hosts really should be using open_basedir. We have
confused them by having both directives, and I see some even enable both
safe_mode and open_basedir on top of each other which doesn't make much
sense. Shared hosts really should be setting an open_basedir on a
per-vhost basis. This will fix file uploads and a number of other
issues and is every bit as safe (or unsafe depending on how you look at
it) as safe_mode.
-Rasmus