Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23185
Return-Path: <iliaal@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 52542 invoked by uid 1010); 7 May 2006 16:18:41 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 52527 invoked from network); 7 May 2006 16:18:41 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 7 May 2006 16:18:41 -0000
X-PHP-List-Original-Sender: iliaal@gmail.com
X-Host-Fingerprint: 64.233.184.224 wr-out-0506.google.com Linux 2.4/2.6
Received: from ([64.233.184.224:2677] helo=wr-out-0506.google.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 05/95-63443-0ED1E544 for <internals@lists.php.net>; Sun, 07 May 2006 12:18:40 -0400
Received: by wr-out-0506.google.com with SMTP id i32so893402wra
	for <internals@lists.php.net>; Sun, 07 May 2006 09:18:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
	b=fbyYB9ZWCxYs4p8oRTOsCwfxyBNgbeTmw1zjILpOcfWnYRut0kgqdMDX6pN3+jmXFBpd6UxDzs74mdNIg0twQD7dBCdnc2a801/2SGVf+81Y7+GmOO+Tf1cIUp+cxUkTF3VN/914iSoGalAElWi20ZVZFowRv7We/z24YliVYmE=
Received: by 10.65.252.6 with SMTP id e6mr646653qbs;
	Sun, 07 May 2006 09:18:36 -0700 (PDT)
Received: from ?192.168.1.6? ( [72.59.8.142])
	by mx.gmail.com with ESMTP id e19sm859305qbe.2006.05.07.09.18.36;
	Sun, 07 May 2006 09:18:36 -0700 (PDT)
In-Reply-To: <445E17ED.8010003@lerdorf.com>
References: <6E5468C5-630C-48B8-A501-6FC874651D01@prohost.org> <445D8156.8090701@lerdorf.com> <506DE35B-1925-4DA7-8F9F-F23F7D77EE87@prohost.org> <445E0BEF.1080403@lerdorf.com> <DF6BD42B-89A4-4F92-879F-070FCDF27681@prohost.org> <445E17ED.8010003@lerdorf.com>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <30AC7F22-70A4-4109-8021-9FBF77D408EE@prohost.org>
Cc: internals Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Sun, 7 May 2006 12:18:33 -0400
To: Rasmus Lerdorf <rasmus@lerdorf.com>
X-Mailer: Apple Mail (2.749.3)
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] PHP 5.2 Branched
From: ilia@prohost.org (Ilia Alshanetsky)


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