Hi,
Going over the todo list I wanted to bring up a few topics once again
for review/discussion (not flaming):
http://oss.backendmedia.com/PhP60
Unicode
3. remove old parameter parsing API and replace with one that
supports unicode related functionality
I just want to remind that when we made some changes to the parameter
parsing API's last time it created some BC issues (like with
array_merge() ..)
5. add unicode to pdo (wez)
Maybe one place where IBM could step up, seeing that they are putting a
lot of resources into their PDO drivers.
cleanups
4. safe_mode/open_basedir
1. remove safe mode and throw `E_CORE_ERROR` when set
2. unbundle safe_mode_exec_dir from safe_mode and keep it
(rasmus) (take a look at this patch too)
3. new ini option: open_basedir_for_include which would allow
using include/require(_once) on an expanded set of directories (sara)
Whats the state here. I remember that there was still a fair bit of back
and forth on this point.
9. remove zend.ze1_compatibility mode and throw `E_CORE_ERROR` when
set DONE (dmitry)
Same here. Gone for good?
PECL
3. regexp
1. make ereg an extension
2. PCRE extension will not be allowed to be disabled.
3. core of PHP should be made to work with PCRE so that we can
safely disable ereg
4. unbundle the regex library
We had a short discussion on this one not too long ago.
5. move mime_magic from the core to PECL
6. fileinfo
1. move the Fileinfo extension to the core, and enable it by
default.
2. Fileinfo extension should be updated to only load its
database once on MINIT.
Didn't we fast track these two to 5.x?
7. ext/soap
1. ext/soap will be turned on by default
2. implement some of the security extensions to ext/soap
3. watch axis2 based implementation development
I am guessing the security stuff could take a bit to implement. Does
anyone feel "responsible" for this item?
Engine additions
2. add a new 64bit integer that is always 64bits regardless of
platform with the cast name for this new type is (int64) and internally
we use IS_INT64 and RETURN_INT64 etc..
Are we still on track with this one?
4. add an ifsetor() construct with the middle value for the ?:
ternary operator dropped
Kinda scared to mention this one. Me want very much though :)
6. speed up @-operator and ask andi for approval (ilia, marcus)
7. add ability to allocate persistent zvals in PHP.
8. add ZEND_ACC_READONLY (marcus)
Just bringing those 3 up as a reminder. It sounds like 6. is done and
just needs a nod? 7. needs someone breaking some brain cycles over and
- is probably trivial to do ..?
OO changes
3. object casting to primitive types BC mess (derick)
Derick could you elaborate on this one?
5. fix __toString() DONE (marcus)
Didn't we fix this one in 5.x already?
6. add internal flag only to force calling of the parent constructor
I guess we have something like this in PDO already. Personally I think
we should have rather promoted the "factories" pattern for extensions as
well. But if we have it for internals stuff, why not also for userland?
7. re-use the "static::" keyword to do runtime evaluation of statics.
This is one of the most wanted features going from user feedback.
8. add namespace support (marcus, jessie)
This topic still alive?
9. add support for type-hinted return values.
Seems like quite a big feature in terms of changing PHP, but could be
quite a nice feature for stuff like soap wsdl generation (though here we
can always fallback on phpdoc parsing).
Other Additions/Changes
2. APC
1. include APC in the core distributions (turned off by
default) and switch to mmap as default shared memory storage.
2. ability to move autoloaded main classes in apc's class
lookup preventing the overhead of doing the inheritance process all the
time. (marcus)
Are we still on track with this one? I remember that Zeev said he was
generally ok with this one, but wanted to ponder it some more.
3. include the patch' real-path fix from hardended php
Wasn't this done already in 5.x?
4. include the protection against HTTP Response Splitting attacks
(header() shouldn't accept multiple headers in one call) from hardended php
Wasn't this done already in 5.x?
5. split allow_url_fopen into two distinct settings: allow_url_fopen
and allow_url_include. If allow_url_fopen is off, then allow_url_include
will be off too.
6. enable allow_url_fopen by default
7. disable allow_url_include by default
Is this still going to happen?
8. add sand boxing if we have a rock solid implementation (sara)
Sara, just making sure you are allocating brain cycles for this on a
daily basis ;)
9. go over the engine and extensions and make sure only `E_ERROR` is
used where the engine is in an unrecoverable state.
Hmm, this sounds like a nice one to get your feet wet in internals
development. Hope I have time to finish Sara's book on my USA trip that
lasts until end of May.
- kill "<%" but keep "<?".
Sounds easy enough to do. Why not do it know, so that we can hear about
the impact for users as early as possible.
- prepare a patch that disallows mixing different open/close tags.
(jani)
Jani .. looks like you are back!? :)
- Output Control
- rewrite DONE (mike)
- revisit existing output handlers (mike)
I remember that Mike was a bit dissapointed with feedback on this one.
Whats the status here Mike?
- add php native mysql driver aka mysqlnd (georg, andrey)
I guess there is a beta out now, which even works with PHP5. Maybe its
time to move the code into phpcvs .. its PHP licensed anyways AFAIK.
Finally here are some undiscussed items which should probably be
discussed and dropped or added to the above list. I think we can
probably through out the majority of these items fairly quickly.
1. reference mess (once and for all) (derick)
2. Only Unicode and binary string types. (andrei)
1. Unicode-related errors should be exceptions
2. keep user-visible API unified: no separate `parse_url()` for IDNA
3. hash hook or interface (george)
4. add autoconversion for parameter parsing api (marcus)
5. add a way to get the internal object directly by parameter
parsing api (marcus)
6. get rid of *_ex() functons in engine where possible (marcus)
7. provide a a replacement for the GD extension, being maintained
and easy to extend (pierre)
8. "ext/pimpmydate", new date/time features, real OO interface (pierre)
9. throwing exceptions in SoapServer? and catching them with
SoapClient? (korving)
- a non-bankers-round
round()variant (korving) - being able to use array() when defining constants (korving)
- regular expression switch-matching (korving)
- add SRM (amico)
- add support for dangling commas
- soap is a cluster-fuck. fix it and add support for wsse/secext
(george) - fix openssl/curl to use stream transports
- provide a global __call for non existing functions (george)
- replace flex with re2c (sascha)
- reimplement ext/zlib based on pecl/http code (mike)
- MFB add RFC1867 fileupload processing hook (stefan)
- Replace flex/bison scripts with re2c/lemon ones as soon as re2c
supports states like flex does. This will fix the memleak issues of the
parser, make the lexer&parser threadsafe and reentrant and allows to use
emalloc on temp blocks automatically. (marcus)
regards,
Lukas
Hi Lukas,
4. safe_mode/open_basedir 1. remove safe mode and throw `E_CORE_ERROR` when set 2. unbundle safe_mode_exec_dir from safe_mode and keep it(rasmus) (take a look at this patch too)
3. new ini option: open_basedir_for_include which would allow
using include/require(_once) on an expanded set of directories (sara)Whats the state here. I remember that there was still a fair bit of back
and forth on this point.
At least safe_mode and magic_quotes are gone. I'm not sure about
safe_mode_exec_dir or open_basedir_for_include.
9. remove zend.ze1_compatibility mode and throw `E_CORE_ERROR` whenset DONE (dmitry)
Same here. Gone for good?
No.
Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change
on 2006/06/05 13:58:52.
I didn't find the discussion but I remember there was some "When did we
decide on that?" posting from Zeev.
4. add an ifsetor() construct with the middle value for the ?:ternary operator dropped
Kinda scared to mention this one. Me want very much though :)
Marcus recently added a ?: Operator which isn't exactly the ifsetor but
close to it.
zend_language_parser.y revision 1.179
date: 2007/03/04 16:25:57; author: helly; state: Exp; lines: +4 -1
- Implement '?:'
[DOC] "expr1 ?: expr1" is a shortcut for: "expr1 ? expr1 : expr2" as
exists in gcc and discussed some time back. Note that this is not
an implementation ifsetor($var, default). While ifsetor would not
generate any message for non existing variables or array indices
the ternary shortcut does. Also the ternary shortcut does a
boolean
evaluation rather then checking for isset(). That way ther ternary
shortcut can work on any expression while ifsetor can only work on
variables. Also to be silent one has do do: "@$expr1 ?: $expr2".
5. fix __toString() DONE (marcus)Didn't we fix this one in 5.x already?
Yes.
5. split allow_url_fopen into two distinct settings: allow_url_fopenand allow_url_include. If allow_url_fopen is off, then allow_url_include
will be off too.
6. enable allow_url_fopen by default
7. disable allow_url_include by defaultIs this still going to happen?
That's in 5.2.0.
9. go over the engine and extensions and make sure only `E_ERROR` isused where the engine is in an unrecoverable state.
Hmm, this sounds like a nice one to get your feet wet in internals
development. Hope I have time to finish Sara's book on my USA trip that
lasts until end of May.
That should meanwhile be the case for most extensions.
All said in my best knowledge and I removed the parts where I wasn't
sure about the state :-)
johannes
No.
Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change
on 2006/06/05 13:58:52.
I didn't find the discussion but I remember there was some "When did we
decide on that?" posting from Zeev.
Ah I'm sorry, reading is hard :-)
The revert only was about the PHP 5 branch. Sorry for the wrong
information.
internals@lists.php.net/msg22098.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg22098.html Would
be the discussion if it still matters then :-)
johannes
Hello Johannes,
Thursday, April 12, 2007, 5:52:57 PM, you wrote:
Hi Lukas,
4. safe_mode/open_basedir 1. remove safe mode and throw `E_CORE_ERROR` when set 2. unbundle safe_mode_exec_dir from safe_mode and keep it(rasmus) (take a look at this patch too)
3. new ini option: open_basedir_for_include which would allow
using include/require(_once) on an expanded set of directories (sara)Whats the state here. I remember that there was still a fair bit of back
and forth on this point.
At least safe_mode and magic_quotes are gone. I'm not sure about
safe_mode_exec_dir or open_basedir_for_include.
9. remove zend.ze1_compatibility mode and throw `E_CORE_ERROR` whenset DONE (dmitry)
Same here. Gone for good?
No.
Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change
on 2006/06/05 13:58:52.
I didn't find the discussion but I remember there was some "When did we
decide on that?" posting from Zeev.
I thought Zeev only brought it back for 5? We agreed for removing it in 6.
If it is still there we drop it. And if someone brings it back he will get
his access removed.
4. add an ifsetor() construct with the middle value for the ?:ternary operator dropped
Kinda scared to mention this one. Me want very much though :)
Marcus recently added a ?: Operator which isn't exactly the ifsetor but
close to it.
No, ifsetor will always be faster. Even @?: isn't the same as there still
error messages will be generated, just not send out.
zend_language_parser.y revision 1.179
date: 2007/03/04 16:25:57; author: helly; state: Exp; lines: +4 -1
- Implement '?:'
[DOC] "expr1 ?: expr1" is a shortcut for: "expr1 ? expr1 : expr2" as
exists in gcc and discussed some time back. Note that this is not
an implementation ifsetor($var, default). While ifsetor would not
generate any message for non existing variables or array indices
the ternary shortcut does. Also the ternary shortcut does a
boolean
evaluation rather then checking for isset(). That way ther ternary
shortcut can work on any expression while ifsetor can only work on
variables. Also to be silent one has do do: "@$expr1 ?: $expr2".
Best regards,
Marcus
Hi Lukas,
Lukas Kahwe Smith wrote:
Hi,
Going over the todo list I wanted to bring up a few topics once again
for review/discussion (not flaming):
http://oss.backendmedia.com/PhP60Unicode
- remove old parameter parsing API and replace with one that
supports unicode related functionalityI just want to remind that when we made some changes to the parameter
parsing API's last time it created some BC issues (like with
array_merge()..)
- add unicode to pdo (wez)
Maybe one place where IBM could step up, seeing that they are putting a
lot of resources into their PDO drivers.cleanups
- safe_mode/open_basedir
- remove safe mode and throw
E_CORE_ERRORwhen set- unbundle safe_mode_exec_dir from safe_mode and keep it
(rasmus) (take a look at this patch too)- new ini option: open_basedir_for_include which would allow
using include/require(_once) on an expanded set of directories (sara)Whats the state here. I remember that there was still a fair bit of back
and forth on this point.
- remove zend.ze1_compatibility mode and throw
E_CORE_ERRORwhen set
DONE (dmitry)Same here. Gone for good?
PECL
- regexp
- make ereg an extension
- PCRE extension will not be allowed to be disabled.
- core of PHP should be made to work with PCRE so that we can
safely disable ereg- unbundle the regex library
We had a short discussion on this one not too long ago.
- move mime_magic from the core to PECL
- fileinfo
- move the Fileinfo extension to the core, and enable it by
default.- Fileinfo extension should be updated to only load its
database once on MINIT.Didn't we fast track these two to 5.x?
- ext/soap
- ext/soap will be turned on by default
- implement some of the security extensions to ext/soap
- watch axis2 based implementation development
I am guessing the security stuff could take a bit to implement. Does
anyone feel "responsible" for this item?Engine additions
- add a new 64bit integer that is always 64bits regardless of
platform with the cast name for this new type is (int64) and internally
we use IS_INT64 and RETURN_INT64 etc..Are we still on track with this one?
- add an ifsetor() construct with the middle value for the ?:
ternary operator droppedKinda scared to mention this one. Me want very much though :)
- speed up @-operator and ask andi for approval (ilia, marcus)
- add ability to allocate persistent zvals in PHP.
This is more like - ask ZE not to clean what it points to when it is
cleaning up the zval, and of course not to allow userland to change it.
I needed a similar thing in mysqlnd and went the route of implementing
it on extension level - doing magic with reference counting. Doing this
means that when the user tries to change the internal buffer pointed by
the zval she performs copy-on-write.
Having ZE support for this will be nice!
Andrey
This is more like - ask ZE not to clean what it points to when it is
cleaning up the zval, and of course not to allow userland to change it.
Well, actually persisting zvals between requests would be very
problematic since it can not then use regular memory allocator (which is
cleaned up at the request end). Which means the engine must know which
allocator allocated the variable, otherwise we'd get a lot of trouble
when mixing such variables in the same context.
Also, it's not clear for me what such variable could be used for. I see
only two potential uses:
- Persistent resources. You don't really need zval then - persist the
resource and allocate zval on need. Resources are refcounted separately,
so no problem. - Caching. Here one would be much better to use external (with regard
to the engine) caching solution - persisting zval would not gain that
much since it's still limited to the process (which may not be either
accessible or alive next time you need it) and overhead of converting
regular zval to persistent one would be roughly the same as overhead for
serializing zval into some form of cache. So I'd leave this to extensions.
Are there any other reasons for persistent zvals?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Yes, if we have persistent zvals we can use objects/arrays as
properties or constants for internal classes. I asked for this 2.5
years ago.
-Andrei
Well, actually persisting zvals between requests would be very
problematic since it can not then use regular memory allocator
(which is cleaned up at the request end). Which means the engine
must know which allocator allocated the variable, otherwise we'd
get a lot of trouble when mixing such variables in the same context.
Also, it's not clear for me what such variable could be used for. I
see only two potential uses:
- Persistent resources. You don't really need zval then - persist
the resource and allocate zval on need. Resources are refcounted
separately, so no problem.- Caching. Here one would be much better to use external (with
regard to the engine) caching solution - persisting zval would not
gain that much since it's still limited to the process (which may
not be either accessible or alive next time you need it) and
overhead of converting regular zval to persistent one would be
roughly the same as overhead for serializing zval into some form of
cache. So I'd leave this to extensions.
Are there any other reasons for persistent zvals?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Yes, if we have persistent zvals we can use objects/arrays as properties
or constants for internal classes. I asked for this 2.5 years ago.
If they are initialized on startup, I think it's doable, though they
shouldn't be directly accessible to the PHP user, since they should be
immutable. So constants are OK, but properties might be a bit of a problem.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
That can be handled with read_property and write_property handlers.
Disallowing access to PHP users is an artificial restriction that we
should find ways around.
-Andrei
Yes, if we have persistent zvals we can use objects/arrays as
properties or constants for internal classes. I asked for this 2.5
years ago.If they are initialized on startup, I think it's doable, though
they shouldn't be directly accessible to the PHP user, since they
should be immutable. So constants are OK, but properties might be a
bit of a problem.Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
That can be handled with read_property and write_property handlers.
Disallowing access to PHP users is an artificial restriction that we
should find ways around.
If you have these handlers, why you need read-made persistent zvals? You
can construct any zval you want once property is read and you can do
anything you want once property is written, what persistent zval would
give you then?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.
-Andrei
That can be handled with read_property and write_property
handlers. Disallowing access to PHP users is an artificial
restriction that we should find ways around.If you have these handlers, why you need read-made persistent
zvals? You can construct any zval you want once property is read
and you can do anything you want once property is written, what
persistent zval would give you then?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.
I think to better understand what would be required a use case would
help a lot. Could you bring forward 1-2 scenarios how one would use it?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.I think to better understand what would be required a use case would
help a lot. Could you bring forward 1-2 scenarios how one would use it?
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Regards,
Michael
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. "module X
has functionality A and B, and to make A work with B I would use
persistent zvals so that when Foo is called Bar happens".
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. "module X
has functionality A and B, and to make A work with B I would use
persistent zvals so that when Foo is called Bar happens".
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:
class c {
static $prop1 = array("foo", "bar");
var $prop2 = array(1,2,3);
}
Regards,
Michael
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:class c {
static $prop1 = array("foo", "bar");
var $prop2 = array(1,2,3);
}
I see, thanks. Are there any existing internal classes that need this
capability?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Yes, PHP-GTK. :)
-Andrei
Sorry for the cryptic reply. I think that initializing a static
class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an
extension:
class c {
static $prop1 = array("foo", "bar");
var $prop2 = array(1,2,3);
}I see, thanks. Are there any existing internal classes that need
this capability?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Yes, PHP-GTK. :)
I don't know much of the GTK, let alone PHP-GTK. What PHP-GTK stores in
static arrays?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
3. remove old parameter parsing API and replace with one thatsupports unicode related functionality
I just want to remind that when we made some changes to the parameter
parsing API's last time it created some BC issues (like with
array_merge()..)
Yes, that's why we need much more tests.
5. add unicode to pdo (wez)Maybe one place where IBM could step up, seeing that they are putting a
lot of resources into their PDO drivers.
As long as it doesn't involve signing a legal paper to submit a patch, I'm all for it.
4. safe_mode/open_basedir 1. remove safe mode and throw `E_CORE_ERROR` when set 2. unbundle safe_mode_exec_dir from safe_mode and keep it(rasmus) (take a look at this patch too)
safe_mode_exec_dir without a safe mode?
Makes little sense to me.
3. new ini option: open_basedir_for_include which would allowusing include/require(_once) on an expanded set of directories (sara)
I'm -1 on this.
9. remove zend.ze1_compatibility mode and throw `E_CORE_ERROR` whenset DONE (dmitry)
Yes, gone in HEAD.
3. regexp 1. make ereg an extension 2. PCRE extension will not be allowed to be disabled. 3. core of PHP should be made to work with PCRE so that we cansafely disable ereg
4. unbundle the regex libraryWe had a short discussion on this one not too long ago.
I can take a look at this (I'm 100% sure nobody is actually interested in new regex extension as long as we have pcre).
Do you have any links on the discussion or do you recall what was the decision?
5. move mime_magic from the core to PECL 6. fileinfo 1. move the Fileinfo extension to the core, and enable it bydefault.
2. Fileinfo extension should be updated to only load its
database once on MINIT.
I already mentioned I'm strongly against moving any extensions from PECL to core.
It should be the other way round.
7. ext/soap 1. ext/soap will be turned on by default 2. implement some of the security extensions to ext/soap 3. watch axis2 based implementation developmentI am guessing the security stuff could take a bit to implement. Does
anyone feel "responsible" for this item?
IIRC Rob was working on some XMLSec stuff, no idea what's its status though..
4. add an ifsetor() construct with the middle value for the ?:ternary operator dropped
Kinda scared to mention this one. Me want very much though :)
Marcus added recently something like this.
5. fix __toString() DONE (marcus)Didn't we fix this one in 5.x already?
Yeah, fixed since 5.2.0.
5. split allow_url_fopen into two distinct settings: allow_url_fopenand allow_url_include. If allow_url_fopen is off, then allow_url_include
will be off too.
6. enable allow_url_fopen by default
7. disable allow_url_include by defaultIs this still going to happen?
Already done (in 5.2.0 IIRC).
- kill "<%" but keep "<?".
Sounds easy enough to do. Why not do it know, so that we can hear about
the impact for users as early as possible.
Yeah, I'll post the patch in a minute..
- prepare a patch that disallows mixing different open/close tags.
(jani)Jani .. looks like you are back!? :)
Yay! =)
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
- kill "<%" but keep "<?".
Sounds easy enough to do. Why not do it know, so that we can hear
about the impact for users as early as possible.Yeah, I'll post the patch in a minute..
Please leave this alone. There is no advantage to removing it and it
breaks existing apps. We have also discussed this and decided against it
after it was posted as one of the suggestions from the Paris meeting.
No need to go over the same argument again.
Edin
Antony Dovgal wrote:
- kill "<%" but keep "<?".
Sounds easy enough to do. Why not do it know, so that we can hear
about the impact for users as early as possible.Yeah, I'll post the patch in a minute..
Please leave this alone. There is no advantage to removing it
Surely there is, we're removing one more useless feature.
and it breaks existing apps.
I've never seen such apps and I doubt they even exist.
And they do, this is PHP3 legacy stuff which won't work in PHP6 anyway.
We have also discussed this and decided against it
after it was posted as one of the suggestions from the Paris meeting.No need to go over the same argument again.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
7. ext/soap 1. ext/soap will be turned on by default 2. implement some of the security extensions to ext/soap 3. watch axis2 based implementation developmentI am guessing the security stuff could take a bit to implement. Does
anyone feel "responsible" for this item?IIRC Rob was working on some XMLSec stuff, no idea what's its status
though..
An XMLSec extension is close to an alpha release. There are a few of us
actually working on it, Alexandre Kalendarev is doing the bulk of the
work right now, and we're almost there. It's based on the xmlsec library
and we decided to add WS-Security functionality directly into that
library and just leverage that functionality, so we keep getting delayed
fixing problems we're creating within xmlsec itself while trying to
maintain BC while adding the functionality we need to hook into it properly.
As far as implementing these into soap, I still think having these as
external extensions that can be accessed from ext/soap rather than
baking directly into ext/soap is best option and would mean just adding
some additional plugin-in points during the message processing. The PHP
code I wrote for WS-Security (which really amounts to only a small
portion of that actualy specs) seems to satisfy at least 90% of the
people looking to implement some of the basic WS-* stack with PHP. The
functionality we are looking to add to an XMLSec extension would not
only help speed up the processing but also expand the amount of
supported algorithms, transformations, etc.. detailed in the specs.
Projects needing to support more complex situations would probably would
want a much larger SOAP framework (like .NET, WCF, XFire, etc.. -
personally I like .NET/WCF here).
As far as axis2 (WSF for PHP), I have been playing around with it for
quite some time now. It still has a lot of bugs to be worked out but
does seem to be aiming to compete with the larger SOAP frameworks. This,
however, is one of the reasons I really don't think it should replace
the existing soap extension. The current source for WSF for PHP is
almost 6MB in size and its not as simple to use as ext/soap. It would
add a lot of bloat and confusion when in most cases creating simple SOAP
clients is the desired functionality. Basically I think it might make a
good alternative for someone to use as a more complex SOAP framework,
but not one to be included in PHP core.
Rob
- move mime_magic from the core to PECL
- fileinfo
- move the Fileinfo extension to the core, and enable it by default.
- Fileinfo extension should be updated to only load its database
once on MINIT.Didn't we fast track these two to 5.x?
Nope, as we'd need to put the database into a .h/.c file so that we
don't have to rely on something external.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hi,
FYI I have updated the todo list according to the recent discussions:
http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02
regards,
Lukas
Hey,
I have a few more questions:
Other Additions/Changes:
- add
E_STRICTtoE_ALLDONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted to
only include E_DEPRECATED in E_ALL and not E_STRICT. Or whats the POV here?
regards,
Lukas
Hey,
I have a few more questions:
Other Additions/Changes:
- add
E_STRICTtoE_ALLDONE (dmitry)Currently the plan is to split
E_STRICTintoE_STRICTandE_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted to
only includeE_DEPRECATEDinE_ALLand not E_STRICT. Or whats the POV here?
My dictionary says that "all" means all, not "all except this and
this and sometimes not that".
-Hannes
regards,
Lukas
Hannes Magnusson wrote:
- add
E_STRICTtoE_ALLDONE (dmitry)My dictionary says that "all" means all, not "all except this and
this and sometimes not that".
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changing E_ALL to include everything would
unnecessarily break existing installations. I think we will have to live
with this misnomer and not try to 'fix' it.
I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
even sure if E_DEPRECATED should be included in E_ALL: It depends on how
liberally things will get marked E_DEPRECATED.
- Chris
Hannes Magnusson wrote:
- add
E_STRICTtoE_ALLDONE (dmitry)My dictionary says that "all" means all, not "all except this and
this and sometimes not that".
E_ALLshould have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changingE_ALLto include everything would
unnecessarily break existing installations. I think we will have to live
with this misnomer and not try to 'fix' it.
How exactly would any app break?
You don't display errors on your production server, do you?
It will only help you understand what is going on while you develop
the application.
I think what we need here is fix our php.ini files: php.ini-production
& php.ini-developing
-Hannes
I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
even sure ifE_DEPRECATEDshould be included in E_ALL: It depends on how
liberally things will get marked E_DEPRECATED.
- Chris
Hannes Magnusson wrote:
- add
E_STRICTtoE_ALLDONE (dmitry)My dictionary says that "all" means all, not "all except this and
this and sometimes not that".
E_ALLshould have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changingE_ALLto include everything would
unnecessarily break existing installations. I think we will have to live
with this misnomer and not try to 'fix' it.How exactly would any app break?
You don't display errors on your production server, do you?
It will only help you understand what is going on while you develop
the application.I think what we need here is fix our php.ini files: php.ini-production
& php.ini-developing-Hannes
In development mode I want to see every single
error/notice/warning/etc. How else am I supposed to know if I've done
something incorrect or the sand has shifted beneath my feet and I
didn't realise?
In production no errors should be displayed (i.e. all nice clean code)
but even if they are they should only be logged and not displayed.
So in both circumstances E_ALL should still mean every single
error/notice/warning/etc.
I do like the idea of production and development ini files. That seems
to make more sense than recommended and dist. I'm sure dist means
distribution, but then what does recommended mean? Without knowing the
reason, seeing recommended and dist are confusing.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hannes Magnusson wrote:
- add
E_STRICTtoE_ALLDONE (dmitry)My dictionary says that "all" means all, not "all except this
and
this and sometimes not that".
E_ALLshould have been called E_RECOMMENDED or E_DEFAULT to avoid
this
confusion but in reality changingE_ALLto include everything would
unnecessarily break existing installations. I think we will have to
live
with this misnomer and not try to 'fix' it.How exactly would any app break?
You don't display errors on your production server, do you?
I don't, but some users do.
If you can get them all to fix that first, we're all set... :-v
It will only help you understand what is going on while you develop
the application.I think what we need here is fix our php.ini files: php.ini-production
& php.ini-developing
That would help quite a bit.
--
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?
Christian Schneider wrote:
I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
Feel like working up a patch for 5.3 for this? :)
regards,
Lukas
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
regards,
Lukas
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
Most of its features could (should?) be moved to ZE2 as they are what
can be considered as part of the language. It is even more important
as some them are required to work around recent changes/fixes in ZE2
(for example __set/__get used with arrays can be done with
ArrayObject). As any other language features, it will not be possible
to disable them.
Doing so will not only help our users but ease the extensions development.
That being said, I never really understood why it was developed
outside ZendEngine2 (at least for the main classes like ArrayObject,
ArrayIterator, iterator_to_array or class_* (these two are the most
obvious candidate!) .
--Pierre