On 7-May-06, at 11:53 AM, Rasmus Lerdorf wrote:
> Ilia Alshanetsky wrote:
>> On 7-May-06, at 11:02 AM, 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.
>>>
>> 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
