On 8-Dec-06, at 2:05 PM, Stefan Esser wrote:
a) support daisy chaining
Can you not provide your own hooks and have them call the stock
filter
functions?
I (my extensions) have no problem with that. I just wonder why PHP got
input filter hooks in one version and in a few versions later they are
not useable anymore, because ext/filter grabs them.
Don't get me wrong its not a bad idea to have daisy chaining, its
just that there was no need for it expressed before so it was never
done.
b) does not register the variables itself but actually work as
filters
were supposed to do.
I think it makes the API simpler, but it would not be major change to
make if there was a really good reason to do so.
The reason is simple: The filter extension abuses the input filtering
hooks. The variables are no longer registered at one single place but
several codepaths lead to different results.
The bug you fixed with your commit is the best example: If ext/filter
would not try to register the variables itself, this bug would never
have happened.
There are a few reasons why it is doing it, foremost of which is the
attempt to reduce the amount of memory utilized while registering
variables. The last thing we want to do is allocate, re-allocate and
so on every input parameter. I suspect there is a way to achieve a
solution that would prevent duplication of data, which we still have
right now with the RAW filter.
c) Support Cookies correctly...
Very simple: In some earlier version php_register_variable_ex was
changed to handle cookies different from other variables: Cookies with
the same name will get dropped after the first is registered.
In ext filter the raw variables still have this behaviour but the
filtered variables behave different...
I need to look into that, I recall adding checks for cookie hierarchy
based on paths into "core" PHP, but I have not played with the
equivalent filter code yet.
Ilia Alshanetsky
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
