PHP 5.2 Branched - Externals

19 years ago by Ilia Alshanetsky — view source — reply

unread

I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is dead to patches except for those fixing security issues
or critical regressions, once 5.2.0 is released, the 5.1 branch will
be discontinued. Over the last week a list of planned changes for
the 5.2 have been compiled on Lukas' wiki (http://
oss.backendmedia.com/PhP52). I've broken down the list into two
sections "confirmed" and "pending discussion" the latter being
changes I am not certain about and would like to hear everyone's
feedback.

Confirmed:

new functions: ext/date: date_sun_info (derick)
Switch for disabling/enabling materialized cursors in mysqli (georg)
add support for files >2GB (wez)
Engine and Language optimizations.

DOM:
* Add the registerNodeClass() function currently in HEAD
* Add Canonical functionality (still trying to figure out
best method signature for this one)
* Update IsID? functionality (code currently in HEAD)

PCRE (MFH)
* cache hooks
* make it possible to set runtime limits on backtracking and
recursion and add preg_last_error()

PDO
* Add PDO::defaultFetchMode attribute (partially done,
remains only fetch_object) (pierre)
* Allow the DSN to be passed as array, proposal phase. An
initial proposal was done here (pierre, lukas)
* PDO: FETCH_PROPS_LATE

SOAP
* SOAP Cache optimizations (Dmitri and Andrei) (technically
it is already in)

SPL
MFH
* SPL: RegExIterator?
* SPL: SplFileObject?: read csv, skip empty lines
* SPL: ArrayIterator?: overload ArrayAccess? support and
array functions
NEW
* SPL: RegExIterator?: ability to pregsplit the matches
* SPL: SplFileObject?: ability to set the CSV separator per
object
* streams (SPL?): leverage memory/temp streams so that a
string can be converted to a stream easily, some registration
interface is nec

PDO SQLite
* Upgrade bundled SQLite 3 library (Ilia)

XSL:
* Add property to perform XInclude during transformation

XMLWriter:
* Synch code with HEAD (code is cleaner and shorter in HEAD)
contains 2 new methods (fullEndElement? and writeRaw)
* Add writeNote([xmlreader obj]), allow to create a push/
pull parser

XMLReader:
* Merge functionality from HEAD
* xmlReader::readInnerXml?
* xmlReader::setSchema
* passing libxml options when loading reader
* add readInnerXML?, readOuterXML?, readString, setSchema
(all require libxml2-2.6.20+)
( use xmlreader const functions (lowers memory usage and
runs faster)

Zend Engine and langages:
* Zend: __toString()
* Zend: interfaces with constructors
* Zend: exception functions TSRM signature (compatible with
HEAD)
* Drop ZE1 compatibility
* E_RECOVERABLE_ERROR

PostgreSQL
* MFH pg_field_table() (edin)

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)
Add json extension via a symlink from pecl into core as experimental
on-the-fly static properties (mike)
'strict class' to disable dynamic member variable addition, see
above (marcus)
main: spprintf 'v' (maybe the zstr stuff?)
Output Buffering rewrite (mike) (uncertain as of yet)

As far as the release plan, the hope is to have 5.2 released within 3
months, with major changes completed within the 1st month and the
remaining 2 month used to get things stable. The tentative date for
RC1 is June 22nd.

Ilia

19 years ago by Wez Furlong — view source — reply

unread

I'd like to add a function that returns tsrm_thread_id(). It would be
present in ZTS builds only, and could be used by code that needs to
generate "unique" identifiers.

I'm open for ideas on what to name it; sys_get_thread_id() or something?

--Wez.

I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is dead to patches except for those fixing security issues
or critical regressions, once 5.2.0 is released, the 5.1 branch will
be discontinued. Over the last week a list of planned changes for
the 5.2 have been compiled on Lukas' wiki (http://
oss.backendmedia.com/PhP52). I've broken down the list into two
sections "confirmed" and "pending discussion" the latter being
changes I am not certain about and would like to hear everyone's
feedback.

Confirmed:

new functions: ext/date: date_sun_info (derick)

Switch for disabling/enabling materialized cursors in mysqli (georg)

add support for files >2GB (wez)

Engine and Language optimizations.

DOM:
* Add the registerNodeClass() function currently in HEAD
* Add Canonical functionality (still trying to figure out
best method signature for this one)
* Update IsID? functionality (code currently in HEAD)

PCRE (MFH)
* cache hooks
* make it possible to set runtime limits on backtracking and
recursion and add preg_last_error()

PDO
* Add PDO::defaultFetchMode attribute (partially done,
remains only fetch_object) (pierre)
* Allow the DSN to be passed as array, proposal phase. An
initial proposal was done here (pierre, lukas)
* PDO: FETCH_PROPS_LATE

SOAP
* SOAP Cache optimizations (Dmitri and Andrei) (technically
it is already in)

SPL
MFH
* SPL: RegExIterator?
* SPL: SplFileObject?: read csv, skip empty lines
* SPL: ArrayIterator?: overload ArrayAccess? support and
array functions
NEW
* SPL: RegExIterator?: ability to pregsplit the matches
* SPL: SplFileObject?: ability to set the CSV separator per
object
* streams (SPL?): leverage memory/temp streams so that a
string can be converted to a stream easily, some registration
interface is nec

PDO SQLite
* Upgrade bundled SQLite 3 library (Ilia)

XSL:
* Add property to perform XInclude during transformation

XMLWriter:
* Synch code with HEAD (code is cleaner and shorter in HEAD)
contains 2 new methods (fullEndElement? and writeRaw)
* Add writeNote([xmlreader obj]), allow to create a push/
pull parser

XMLReader:
* Merge functionality from HEAD
* xmlReader::readInnerXml?
* xmlReader::setSchema
* passing libxml options when loading reader
* add readInnerXML?, readOuterXML?, readString, setSchema
(all require libxml2-2.6.20+)
( use xmlreader const functions (lowers memory usage and
runs faster)

Zend Engine and langages:
* Zend: __toString()
* Zend: interfaces with constructors
* Zend: exception functions TSRM signature (compatible with
HEAD)
* Drop ZE1 compatibility
* E_RECOVERABLE_ERROR

PostgreSQL
* MFH pg_field_table() (edin)

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as experimental

on-the-fly static properties (mike)

'strict class' to disable dynamic member variable addition, see
above (marcus)

main: spprintf 'v' (maybe the zstr stuff?)

Output Buffering rewrite (mike) (uncertain as of yet)

As far as the release plan, the hope is to have 5.2 released within 3
months, with major changes completed within the 1st month and the
remaining 2 month used to get things stable. The tentative date for
RC1 is June 22nd.

Ilia

19 years ago by Sara Golemon — view source — reply

unread

I'd like to add a function that returns tsrm_thread_id().
It would be present in ZTS builds only, and could be used
by code that needs to generate "unique" identifiers.

I'm open for ideas on what to name it; sys_get_thread_id()
or something?

How about zend_thread_id()? (Present since 5.0.0)

I hadn't seen this one until just now either...

-Sara

19 years ago by Wez Furlong — view source — reply

unread

Oooo. Would be nice if that could make it into the manual.

--Wez.

I'd like to add a function that returns tsrm_thread_id().
It would be present in ZTS builds only, and could be used
by code that needs to generate "unique" identifiers.

I'm open for ideas on what to name it; sys_get_thread_id()
or something?

How about zend_thread_id()? (Present since 5.0.0)

I hadn't seen this one until just now either...

-Sara

19 years ago by Brian J. France — view source — reply

unread

Could the curl_multi_info_read patch be considered for the 5.2 branch?

Thanks,

Brian

I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch. The
5.1 branch is dead to patches except for those fixing security
issues or critical regressions, once 5.2.0 is released, the 5.1
branch will be discontinued. Over the last week a list of planned
changes for the 5.2 have been compiled on Lukas' wiki (http://
oss.backendmedia.com/PhP52). I've broken down the list into two
sections "confirmed" and "pending discussion" the latter being
changes I am not certain about and would like to hear everyone's
feedback.

Confirmed:

new functions: ext/date: date_sun_info (derick)

Switch for disabling/enabling materialized cursors in mysqli (georg)

add support for files >2GB (wez)

Engine and Language optimizations.

DOM:
* Add the registerNodeClass() function currently in HEAD
* Add Canonical functionality (still trying to figure out
best method signature for this one)
* Update IsID? functionality (code currently in HEAD)

PCRE (MFH)
* cache hooks
* make it possible to set runtime limits on backtracking and
recursion and add preg_last_error()

PDO
* Add PDO::defaultFetchMode attribute (partially done,
remains only fetch_object) (pierre)
* Allow the DSN to be passed as array, proposal phase. An
initial proposal was done here (pierre, lukas)
* PDO: FETCH_PROPS_LATE

SOAP
* SOAP Cache optimizations (Dmitri and Andrei) (technically
it is already in)

SPL
MFH
* SPL: RegExIterator?
* SPL: SplFileObject?: read csv, skip empty lines
* SPL: ArrayIterator?: overload ArrayAccess? support and
array functions
NEW
* SPL: RegExIterator?: ability to pregsplit the matches
* SPL: SplFileObject?: ability to set the CSV separator per
object
* streams (SPL?): leverage memory/temp streams so that a
string can be converted to a stream easily, some registration
interface is nec

PDO SQLite
* Upgrade bundled SQLite 3 library (Ilia)

XSL:
* Add property to perform XInclude during transformation

XMLWriter:
* Synch code with HEAD (code is cleaner and shorter in
HEAD) contains 2 new methods (fullEndElement? and writeRaw)
* Add writeNote([xmlreader obj]), allow to create a push/
pull parser

XMLReader:
* Merge functionality from HEAD
* xmlReader::readInnerXml?
* xmlReader::setSchema
* passing libxml options when loading reader
* add readInnerXML?, readOuterXML?, readString, setSchema
(all require libxml2-2.6.20+)
( use xmlreader const functions (lowers memory usage and
runs faster)

Zend Engine and langages:
* Zend: __toString()
* Zend: interfaces with constructors
* Zend: exception functions TSRM signature (compatible with
HEAD)
* Drop ZE1 compatibility
* E_RECOVERABLE_ERROR

PostgreSQL
* MFH pg_field_table() (edin)

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as experimental

on-the-fly static properties (mike)

'strict class' to disable dynamic member variable addition, see
above (marcus)

main: spprintf 'v' (maybe the zstr stuff?)

Output Buffering rewrite (mike) (uncertain as of yet)

As far as the release plan, the hope is to have 5.2 released within
3 months, with major changes completed within the 1st month and the
remaining 2 month used to get things stable. The tentative date for
RC1 is June 22nd.

Ilia

19 years ago by Ilia Alshanetsky — view source — reply

unread

Yeah, feel free to MFH that patch.

Could the curl_multi_info_read patch be considered for the 5.2 branch?

Thanks,

Brian

I've just created the PHP 5.2 branch from which future 5.X release
will be made, so please update your local trees to this branch.
The 5.1 branch is dead to patches except for those fixing security
issues or critical regressions, once 5.2.0 is released, the 5.1
branch will be discontinued. Over the last week a list of planned
changes for the 5.2 have been compiled on Lukas' wiki (http://
oss.backendmedia.com/PhP52). I've broken down the list into two
sections "confirmed" and "pending discussion" the latter being
changes I am not certain about and would like to hear everyone's
feedback.

Confirmed:

new functions: ext/date: date_sun_info (derick)

Switch for disabling/enabling materialized cursors in mysqli
(georg)

add support for files >2GB (wez)

Engine and Language optimizations.

DOM:
* Add the registerNodeClass() function currently in HEAD
* Add Canonical functionality (still trying to figure out
best method signature for this one)
* Update IsID? functionality (code currently in HEAD)

PCRE (MFH)
* cache hooks
* make it possible to set runtime limits on backtracking and
recursion and add preg_last_error()

PDO
* Add PDO::defaultFetchMode attribute (partially done,
remains only fetch_object) (pierre)
* Allow the DSN to be passed as array, proposal phase. An
initial proposal was done here (pierre, lukas)
* PDO: FETCH_PROPS_LATE

SOAP
* SOAP Cache optimizations (Dmitri and Andrei)
(technically it is already in)

SPL
MFH
* SPL: RegExIterator?
* SPL: SplFileObject?: read csv, skip empty lines
* SPL: ArrayIterator?: overload ArrayAccess? support and
array functions
NEW
* SPL: RegExIterator?: ability to pregsplit the matches
* SPL: SplFileObject?: ability to set the CSV separator
per object
* streams (SPL?): leverage memory/temp streams so that a
string can be converted to a stream easily, some registration
interface is nec

PDO SQLite
* Upgrade bundled SQLite 3 library (Ilia)

XSL:
* Add property to perform XInclude during transformation

XMLWriter:
* Synch code with HEAD (code is cleaner and shorter in
HEAD) contains 2 new methods (fullEndElement? and writeRaw)
* Add writeNote([xmlreader obj]), allow to create a push/
pull parser

XMLReader:
* Merge functionality from HEAD
* xmlReader::readInnerXml?
* xmlReader::setSchema
* passing libxml options when loading reader
* add readInnerXML?, readOuterXML?, readString, setSchema
(all require libxml2-2.6.20+)
( use xmlreader const functions (lowers memory usage and
runs faster)

Zend Engine and langages:
* Zend: __toString()
* Zend: interfaces with constructors
* Zend: exception functions TSRM signature (compatible
with HEAD)
* Drop ZE1 compatibility
* E_RECOVERABLE_ERROR

PostgreSQL
* MFH pg_field_table() (edin)

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as
experimental

on-the-fly static properties (mike)

'strict class' to disable dynamic member variable addition, see
above (marcus)

main: spprintf 'v' (maybe the zstr stuff?)

Output Buffering rewrite (mike) (uncertain as of yet)

As far as the release plan, the hope is to have 5.2 released
within 3 months, with major changes completed within the 1st month
and the remaining 2 month used to get things stable. The tentative
date for RC1 is June 22nd.

Ilia

--

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

19 years ago by Rasmus Lerdorf — view source — reply

unread

Ilia Alshanetsky wrote:

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as experimental

Haven't we discussed these two enough? Does someone actually disagree
with pushing these in as soon as possible?

-Rasmus

19 years ago by Marcus Boerger — view source — reply

unread

Hello Rasmus,

Sunday, May 7, 2006, 7:10:46 AM, you wrote:

Ilia Alshanetsky wrote:

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as experimental

Haven't we discussed these two enough? Does someone actually disagree
with pushing these in as soon as possible?

I was also under the impression that we agreed already.

Best regards,
Marcus

19 years ago by Pierre — view source — reply

unread

On Sat, 06 May 2006 22:10:46 -0700
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

Ilia Alshanetsky wrote:

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as
experimental

Haven't we discussed these two enough? Does someone actually
disagree with pushing these in as soon as possible?

Yes we already agreed on these two additions.

-- Pierre

19 years ago by Ilia Alshanetsky — view source — reply

unread

I am +0 on these two extensions, hence the "to be discussed", as long
as they are not enabled by default I see no problem with symlinking
them in.

Ilia Alshanetsky wrote:

Pending Discussion:

Add input filter extension via a symlink from pecl into core as
experimental (derick)

Add json extension via a symlink from pecl into core as
experimental

Haven't we discussed these two enough? Does someone actually
disagree with pushing these in as soon as possible?

-Rasmus

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

19 years ago by Rasmus Lerdorf — view source — reply

unread

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as long as
they are not enabled by default I see no problem with symlinking them in.

I'd like to see the json extension enabled by default. It's a trivially
small extension with no external deps and pretty much required for
modern Web apps.

And I think the filter extension should be enabled as well, but without
the default filter turned on to make the filtering functions available.

-Rasmus

19 years ago by Pierre — view source — reply

unread

On Sun, 07 May 2006 08:02:07 -0700
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in.

I'd like to see the json extension enabled by default. It's a
trivially small extension with no external deps and pretty much
required for modern Web apps.

And I think the filter extension should be enabled as well, but
without the default filter turned on to make the filtering functions
available.

I also like to have it enabled by default and without default filter.

In case some of you never tested pecl/filter, the default filter
is a SAPI filter. It filters each inputs and replaces the raw values by
the filtered values in all superglobals, like _POST/_GET. Enable it by
default now will break every applications, as soon as it is set to
something else than raw. STRING is the default mode (remove every tags,
new lines, special chars,...).

-- Pierre

19 years ago by Marcus Boerger — view source — reply

unread

Hello Rasmus,

same here, i see nothing that speaks against enabling by default. Indeed
didn't we all want to have ext filter as default enabled from the start?
And i can only second Rasmus that json is necessary for Web 2.0 to name the
beast.

marcus

Sunday, May 7, 2006, 5:02:07 PM, you wrote:

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as long as
they are not enabled by default I see no problem with symlinking them in.

I'd like to see the json extension enabled by default. It's a trivially
small extension with no external deps and pretty much required for
modern Web apps.

And I think the filter extension should be enabled as well, but without
the default filter turned on to make the filtering functions available.

-Rasmus

Best regards,
Marcus

19 years ago by Derick Rethans — view source — reply

unread

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as long as
they are not enabled by default I see no problem with symlinking them in.

...

And I think the filter extension should be enabled as well, but without the
default filter turned on to make the filtering functions available.

Yeah, me too.

Derick

19 years ago by Ilia Alshanetsky — view source — reply

unread

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in.

I'd like to see the json extension enabled by default. It's a
trivially small extension with no external deps and pretty much
required for modern Web apps.

That's stretching it a bit, don't you think? I don't deny that JSON
extension is useful, but "required" for modern apps, c'mon...

And I think the filter extension should be enabled as well, but
without the default filter turned on to make the filtering
functions available.

What impact would it have on the speed of input processing if it is
always there, but not doing anything? I'd prefer to avoid adding
extra overhead for something that does nothing by default, we have
enough performance issues as is in 5.X. Pierre and Derick are telling
me that if the RAW filter is enabled it won't touch the data so
perhaps that's the route we should take, but I'd definitely like to
see before & after benchmarks.

Ilia

19 years ago by Rasmus Lerdorf — view source — reply

unread

Ilia Alshanetsky wrote:

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as long
as they are not enabled by default I see no problem with symlinking
them in.

I'd like to see the json extension enabled by default. It's a
trivially small extension with no external deps and pretty much
required for modern Web apps.

That's stretching it a bit, don't you think? I don't deny that JSON
extension is useful, but "required" for modern apps, c'mon...

I can't think of anything I have written, or anybody around me has
written in the past 6 months that didn't need json. Yes, I guess if you
have no Javascript at all, then you don't need json, but if you do any
Javascript, it is the only sane way to transfer data from PHP to
Javascript. Even if you don't use Ajax-like backend requests, a simple:

Is so much easier, cleaner and safer than any other mechanisms you can
throw at this. The fact that we didn't get this into PHP sooner is
actually a bit sad as far as I am concerned.

And I think the filter extension should be enabled as well, but
without the default filter turned on to make the filtering functions
available.

What impact would it have on the speed of input processing if it is
always there, but not doing anything? I'd prefer to avoid adding extra
overhead for something that does nothing by default, we have enough
performance issues as is in 5.X. Pierre and Derick are telling me that
if the RAW filter is enabled it won't touch the data so perhaps that's
the route we should take, but I'd definitely like to see before & after
benchmarks.

It won't touch the data, but that doesn't mean it isn't useful. Being
able to do:

echo input_get(INPUT_SERVER, "SCRIPT_URI", FILTER_SANITIZE_URL);

or using the new input_get_args() function to completely and safely
specify all your input parameters to a page is also a big win.

-Rasmus

19 years ago by Ilia Alshanetsky — view source — reply

unread

Ilia Alshanetsky wrote:

Ilia Alshanetsky wrote:

I am +0 on these two extensions, hence the "to be discussed", as
long as they are not enabled by default I see no problem with
symlinking them in.

I'd like to see the json extension enabled by default. It's a
trivially small extension with no external deps and pretty much
required for modern Web apps.

That's stretching it a bit, don't you think? I don't deny that
JSON extension is useful, but "required" for modern apps, c'mon...

I can't think of anything I have written, or anybody around me has
written in the past 6 months that didn't need json. Yes, I guess
if you have no Javascript at all, then you don't need json, but if
you do any Javascript, it is the only sane way to transfer data
from PHP to Javascript. Even if you don't use Ajax-like backend
requests, a simple:
<script> var data = <?php echo json_encode($php_data)?>; </script>
Is so much easier, cleaner and safer than any other mechanisms you
can throw at this. The fact that we didn't get this into PHP
sooner is actually a bit sad as far as I am concerned

Well, I have written quite a few application in the past few years
and many of them have used JavaScript in one way or another and only
in few instances did the amount of data involve required something as
evolved as JSON. Every extension in PECL exists because someone out
there has a need for the functionality no matter how obscure it may
seem to the rest of us. JSON certainly seems like something that
could be of use to a large group from what I am hearing on and off
the list, so lets link it in.

And I think the filter extension should be enabled as well, but
without the default filter turned on to make the filtering
functions available.
What impact would it have on the speed of input processing if it
is always there, but not doing anything? I'd prefer to avoid
adding extra overhead for something that does nothing by default,
we have enough performance issues as is in 5.X. Pierre and Derick
are telling me that if the RAW filter is enabled it won't touch
the data so perhaps that's the route we should take, but I'd
definitely like to see before & after benchmarks.

It won't touch the data, but that doesn't mean it isn't useful.
Being able to do:

echo input_get(INPUT_SERVER, "SCRIPT_URI", FILTER_SANITIZE_URL);

or using the new input_get_args() function to completely and safely
specify all your input parameters to a page is also a big win.

Well that can still work, we can access the data from PG
(http_globals) without having to duplicate the data at the onset.

Ilia

19 years ago by Rasmus Lerdorf — view source — reply

unread

Ilia Alshanetsky wrote:

Well that can still work, we can access the data from PG(http_globals)
without having to duplicate the data at the onset.

Not if we don't enable the extension which is what we are talking about.

-Rasmus

19 years ago by Derick Rethans — view source — reply

unread

Ilia Alshanetsky wrote:

Well that can still work, we can access the data from PG(http_globals)
without having to duplicate the data at the onset.

Not if we don't enable the extension which is what we are talking about.

Well, we should enable it by default with the default filter set to
raw... otherwise folks still don't have the input_get functionality
which is the basic point of this extension to me. For me this is much
more useful then JSON...

Derick

19 years ago by Antony Dovgal — view source — reply

unread

Ilia Alshanetsky wrote:

Well that can still work, we can access the data from PG(http_globals)
without having to duplicate the data at the onset.

Not if we don't enable the extension which is what we are talking about.

Well, we should enable it by default with the default filter set to
raw... otherwise folks still don't have the input_get functionality
which is the basic point of this extension to me. For me this is much
more useful then JSON...

Agree, we need to enable it by default, otherwise including it in the core doesn't make much sense.

--
Wbr,
Antony Dovgal

19 years ago by Pierre — view source — reply

unread

Agree, we need to enable it by default, otherwise including it in the core doesn't make much sense.

Please read my answers in this thread and my post from today about the
current filter status.

--Pierre

19 years ago by Pierre — view source — reply

unread

Hello,

What impact would it have on the speed of input processing if it is
always there, but not doing anything? I'd prefer to avoid adding
extra overhead for something that does nothing by default, we have
enough performance issues as is in 5.X. Pierre and Derick are telling
me that if the RAW filter is enabled it won't touch the data so
perhaps that's the route we should take, but I'd definitely like to
see before & after benchmarks.

The current code calls the sapi filter, no matter if the filter is set
to UNSAFE_RAW (data unchanged) or not.

I already tested an alternative solution. It is possible to do not
register the sapi filter and use PG(http_globals)[...] directly in
input_get (and input_get_args). Doing so will minimize any possible
performance impact.

--Pierre

19 years ago by Lukas Smith — view source — reply

unread

Ilia Alshanetsky wrote:

discontinued. Over the last week a list of planned changes for the 5.2
have been compiled on Lukas' wiki (http://oss.backendmedia.com/PhP52).

I have updated the wiki page with Ilia's list. I added a few items that
I still marked as todo in my email client into the "open for discussion"
list.

regards,
Lukas