# JSON inclusion in core - Thread: https://externals.io/message/21591 - Original archive: https://news-web.php.net/php.internals/21591 - Started by Rasmus Lerdorf on 2006-01-20T19:31:58+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/21591.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #21591 — Rasmus Lerdorf — 2006-01-20T19:31:58+00:00 URL: https://externals.io/message/21591#21591 pecl/json is a rather simple extension with no external deps (it bundles the small library it uses). The JSON format is stable with no real possibility of changing basically by definition, and I see its use exploding this year. There is also talk to a JSON Request object being added to browsers and if that happens we need to support that natively much like we support url-encoded form data ending up directly in $_POST. I could see a $_JSON if browsers start sending this. But, as an initial step how about we bundle pecl/json in the next release? There is an issue with the fact that it is LGPL'ed. But perhaps we can work with Omar to put at least the extension part under the PHP license when bundled with PHP. -Rasmus --- ## #21592 — Marcus Boerger — 2006-01-20T19:49:46+00:00 URL: https://externals.io/message/21591#21592 · In reply to: #21591 Hello Rasmus, Friday, January 20, 2006, 8:31:58 PM, you wrote: > pecl/json is a rather simple extension with no external deps (it bundles > the small library it uses). The JSON format is stable with no real > possibility of changing basically by definition, and I see its use > exploding this year. There is also talk to a JSON Request object being > added to browsers and if that happens we need to support that natively > much like we support url-encoded form data ending up directly in $_POST. > I could see a $_JSON if browsers start sending this. But, as an > initial step how about we bundle pecl/json in the next release? > There is an issue with the fact that it is LGPL'ed. But perhaps we can > work with Omar to put at least the extension part under the PHP license > when bundled with PHP. I don't care for the lib itself whether we bundle or not. The extension should however change to PHP License just like XmlWriter needed to change. Best regards, Marcus --- ## #21593 — Ilia Alshanetsky — 2006-01-20T21:08:19+00:00 URL: https://externals.io/message/21591#21593 · In reply to: #21591 As long as the extension is licensed under the PHP License, I don't see a problem with including in PHP 6. Ilia --- ## #21594 — Andi Gutmans — 2006-01-20T21:49:12+00:00 URL: https://externals.io/message/21591#21594 · In reply to: #21591 Hey, I think having a JSON extension for PHP is a good idea. We have written our own implementation in PHP for framework but could definitely benefit from a C extension down the road if it gets widely adopted. My only concern is that this is a very new extension and I haven't seen any docs yet. So generally speaking I'd be a +1 but I prefer to be able to first review docs, make sure APIs are reasonable and the best they can be, and then keep it experimental for a while to make sure it's stable (which would have probably been the case anyway). Andi At 11:31 AM 1/20/2006, Rasmus Lerdorf wrote: >pecl/json is a rather simple extension with no external deps (it >bundles the small library it uses). The JSON format is stable with >no real possibility of changing basically by definition, and I see >its use exploding this year. There is also talk to a JSON Request >object being added to browsers and if that happens we need to >support that natively much like we support url-encoded form data >ending up directly in $_POST. I could see a $_JSON if browsers >start sending this. But, as an initial step how about we bundle >pecl/json in the next release? > >There is an issue with the fact that it is LGPL'ed. But perhaps we >can work with Omar to put at least the extension part under the PHP >license when bundled with PHP. > >-Rasmus --- ## #21595 — Jani Taskinen — 2006-01-20T22:02:24+00:00 URL: https://externals.io/message/21591#21595 · In reply to: #21594 What about pecl/filter ?! I find that much more important and useful than any yet-another-must-have-because-it-is-sexy-and-buzzword-compliant extension.. --Jani > > Hey, > > I think having a JSON extension for PHP is a good idea. We have written our > own implementation in PHP for framework but could definitely benefit from a C > extension down the road if it gets widely adopted. > > My only concern is that this is a very new extension and I haven't seen any > docs yet. So generally speaking I'd be a +1 but I prefer to be able to first > review docs, make sure APIs are reasonable and the best they can be, and then > keep it experimental for a while to make sure it's stable (which would have > probably been the case anyway). > > Andi > > At 11:31 AM 1/20/2006, Rasmus Lerdorf wrote: > > […] --- ## #21596 — Rasmus Lerdorf — 2006-01-20T22:21:16+00:00 URL: https://externals.io/message/21591#21596 · In reply to: #21594 It's pretty simple. string json_encode(mixed whatever) mixed json_decode(string encoded_whatever) It's just a serializer. -Rasmus Andi Gutmans wrote: > Hey, > > I think having a JSON extension for PHP is a good idea. We have written > our own implementation in PHP for framework but could definitely benefit > from a C extension down the road if it gets widely adopted. > > My only concern is that this is a very new extension and I haven't seen > any docs yet. So generally speaking I'd be a +1 but I prefer to be able > to first review docs, make sure APIs are reasonable and the best they > can be, and then keep it experimental for a while to make sure it's > stable (which would have probably been the case anyway). > > Andi > > At 11:31 AM 1/20/2006, Rasmus Lerdorf wrote: > > […] --- ## #21597 — Andi Gutmans — 2006-01-21T00:08:53+00:00 URL: https://externals.io/message/21591#21597 · In reply to: #21595 JSON is actually useful for real-world apps and not only for buzzword-compliance :) At 02:02 PM 1/20/2006, Jani Taskinen wrote: > yet-another-must-have-because-it-is-sexy-and-buzzword-compliant > extension.. --- ## #21598 — Derick Rethans — 2006-01-21T00:30:03+00:00 URL: https://externals.io/message/21591#21598 · In reply to: #21597 > JSON is actually useful for real-world apps and not only for > buzzword-compliance :) But so is pecl/filter ... Derick --- ## #21599 — Pierre Joye — 2006-01-21T00:43:51+00:00 URL: https://externals.io/message/21591#21599 · In reply to: #21597 > JSON is actually useful for real-world apps and not only for > buzzword-compliance :) A release could help to get a wider audience. It is not yet available for common users under pecl.php.net. --Pierre --- ## #21600 — Jani Taskinen — 2006-01-21T00:51:25+00:00 URL: https://externals.io/message/21591#21600 · In reply to: #21597 I'm not against this extension. I'd just very much like to see the filter extension finally in core as was promised for 5.1.0 once upon the time..IIRC. --Jani > > JSON is actually useful for real-world apps and not only for > buzzword-compliance :) > > At 02:02 PM 1/20/2006, Jani Taskinen wrote: > > […] --- ## #21601 — Andi Gutmans — 2006-01-21T01:02:15+00:00 URL: https://externals.io/message/21591#21601 · In reply to: #21600 I've always been in favor of having ext/filter in standard PHP. It's time we added some security supporting features. Only thing I'd like to do before that is improve the naming conventions a bit. Functions filter_* and I think the constant naming like FL_* and FS_* is a bit confusing. But those are things that can be finalized and changed within a day. Andi At 04:51 PM 1/20/2006, Jani Taskinen wrote: > I'm not against this extension. I'd just very much like to > see the filter extension finally in core as was promised > for 5.1.0 once upon the time..IIRC. > > --Jani > > > > > > […] --- ## #21602 — Andi Gutmans — 2006-01-21T01:03:56+00:00 URL: https://externals.io/message/21591#21602 · In reply to: #21596 Yeah, but the main problem with this kind of stuff is when you start mapping classes and even references. I think it requires some additional pluming to be really useful for writing robust JavaScript<-->PHP connectivity so that it's flexible enough for all those PHP packages to start using it. I'm +1 for including JSON but not on the way the API is defined right now. Andi At 02:21 PM 1/20/2006, Rasmus Lerdorf wrote: >It's pretty simple. > > string json_encode(mixed whatever) > mixed json_decode(string encoded_whatever) > >It's just a serializer. > >-Rasmus > >Andi Gutmans wrote: > > […] --- ## #21603 — Omar Kilani — 2006-01-21T01:17:18+00:00 URL: https://externals.io/message/21591#21603 · In reply to: #21592 Rasmus, Marcus, > Friday, January 20, 2006, 8:31:58 PM, you wrote: > > > […] > > > […] > > I don't care for the lib itself whether we bundle or not. The extension > should however change to PHP License just like XmlWriter needed to change. I've modified the license back to the PHP license in cvs. The reason I switched to the LGPL in the first place is so that Debian would allow inclusion of the package. :) > Best regards, > Marcus Regards, Omar --- ## #21604 — Pierre Joye — 2006-01-21T01:34:38+00:00 URL: https://externals.io/message/21591#21604 · In reply to: #21603 > I've modified the license back to the PHP license in cvs. > > The reason I switched to the LGPL in the first place is so that Debian > would allow inclusion of the package. :) The debian (and other distros) problem is solved by the PHP License 3.01. There is a long thread on this topic in debian-legal list :) --Pierre --- ## #21605 — Andi Gutmans — 2006-01-21T01:34:42+00:00 URL: https://externals.io/message/21591#21605 · In reply to: #21603 At 05:17 PM 1/20/2006, Omar Kilani wrote: >Rasmus, Marcus, > > > […] > >I've modified the license back to the PHP license in cvs. > >The reason I switched to the LGPL in the first place is so that >Debian would allow inclusion of the package. :) Ah OK. Please be sure to also change the license of the library itself. As far as Debian is concerned, you'll be in the same boat as PHP which is an OK place to be in as far as I'm concerned :) Andi --- ## #21607 — Rasmus Lerdorf — 2006-01-21T02:01:49+00:00 URL: https://externals.io/message/21591#21607 · In reply to: #21602 Andi Gutmans wrote: > Yeah, but the main problem with this kind of stuff is when you start > mapping classes and even references. I think it requires some additional > pluming to be really useful for writing robust JavaScript<-->PHP > connectivity so that it's flexible enough for all those PHP packages to > start using it. > I'm +1 for including JSON but not on the way the API is defined right now. I guess I am confused. Javascript, and thus JSON, has no concept of an object. It has something it calls an object, but that is just an associative array. Are you trying to layer some other syntax on top of JSON to convey more meaning than what JSON/Javascript natively supports? I have looped in Douglas Crockford on this. I am about to hop on a plane and will be somewhat out of touch for the next couple of days, but he is the authority on this stuff so please run your proposed api by him. -Rasmus --- ## #21608 — Rasmus Lerdorf — 2006-01-21T02:15:19+00:00 URL: https://externals.io/message/21591#21608 · In reply to: #21601 I am all for the filter extension as well obviously, but I agree there is a bit of cleanup needed and I have a bunch of things I'd like to see in it, but none of them necessarily block adding it. As far as promising it for 5.1.0? I don't recall that being the case. It wasn't ready when we rolled the first 5.1.0 packages. -Rasmus Andi Gutmans wrote: > I've always been in favor of having ext/filter in standard PHP. It's > time we added some security supporting features. > Only thing I'd like to do before that is improve the naming conventions > a bit. Functions filter_* and I think the constant naming like FL_* and > FS_* is a bit confusing. But those are things that can be finalized and > changed within a day. > > Andi > > At 04:51 PM 1/20/2006, Jani Taskinen wrote: > > > […] --- ## #21610 — Andi Gutmans — 2006-01-21T02:29:32+00:00 URL: https://externals.io/message/21591#21610 · In reply to: #21607 At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote: >Andi Gutmans wrote: > > […] > >I guess I am confused. Javascript, and thus JSON, has no concept of >an object. It has something it calls an object, but that is just an >associative array. Are you trying to layer some other syntax on top >of JSON to convey more meaning than what JSON/Javascript natively supports? Yes exactly. So for example, we should define some special string/value pair that conveys the class of the object (e.g. __classname:MyClass). I'd say that this is almost critical to allow a very nice mapping between the client side Javascript and the PHP layer. This way you can pretty much do a 1:1 mapping from Javascript objects (which might be nested) to PHP objects. The decode() would just find this __classname and make sure to instantiate MyClass and put the key/value pairs in that. I did look at Omar's code and it seems it doesn't have such provisions but that said, it's hard to review as I can't see any test cases nor documentation. Maybe Omar can work on that and then we can provide quick feedback and make sure we do something which we're all happy with. Seems like the existing functionality is 90% there. >I have looped in Douglas Crockford on this. I am about to hop on a >plane and will be somewhat out of touch for the next couple of days, >but he is the authority on this stuff so please run your proposed api by him. Great. Andi --- ## #21611 — Andi Gutmans — 2006-01-21T02:32:03+00:00 URL: https://externals.io/message/21591#21611 · In reply to: #21608 At 06:15 PM 1/20/2006, Rasmus Lerdorf wrote: >I am all for the filter extension as well obviously, but I agree >there is a bit of cleanup needed and I have a bunch of things I'd >like to see in it, but none of them necessarily block adding it. Not sure about the functionality, and I agree some of it can probably way, but I would want to finalize the naming before so that we don't have to change it and have another BC mode. >As far as promising it for 5.1.0? I don't recall that being the >case. It wasn't ready when we rolled the first 5.1.0 packages. Yeah I don't remember that either but again, I'm all in favor, but let's just iron out the naming and other feedback which is deemed as critical (if it's just additional non-API affecting features, those can always be added later on) Andi >-Rasmus > >Andi Gutmans wrote: > > […] --- ## #21612 — Hannes Magnusson — 2006-01-21T02:53:27+00:00 URL: https://externals.io/message/21591#21612 · In reply to: #21611 > At 06:15 PM 1/20/2006, Rasmus Lerdorf wrote: > > […] > > Not sure about the functionality, and I agree some of it can probably > way, but I would want to finalize the naming before so that we don't > have to change it and have another BC mode. > > > […] > > Yeah I don't remember that either but again, I'm all in favor, but http://benramsey.com/archives/pecl-input-filter/ quote: "Yet, recently (15 Nov), I noticed that Jani Taskinen (a.k.a. "sniper") checked in some revisions with the comment "Prepare for including in PHP core." This got me thinking, so I asked Derick, and Derick confirmed that the Input Filter extension will be a part of the PHP core in versions 5.1.1 and 6.0." Never noticed any discussions about it in here about including it in PHP5.1. I however would love to see it in the next release. - Hannes > let's just iron out the naming and other feedback which is deemed as > critical (if it's just additional non-API affecting features, those > can always be added later on) > > Andi > > > > […] --- ## #21614 — Jani Taskinen — 2006-01-21T10:23:14+00:00 URL: https://externals.io/message/21591#21614 · In reply to: #21611 > Not sure about the functionality, and I agree some of it can probably way, but Way..wait? :) > I would want to finalize the naming before so that we don't have to change it > and have another BC mode. If the naming is the only problem, I can fix that in a minute. And only thing needing any renaming are these (with my proposal): FS_ and FL_ => FILTER_TYPE_ (IMO it's not necessary to separate these) FC_CALLBACK => `FILTER_CALLBACK` (there's just one) --Jani --- ## #21618 — Derick Rethans — 2006-01-21T12:48:54+00:00 URL: https://externals.io/message/21591#21618 · In reply to: #21614 > > > […] > > Way..wait? :) > > > […] > > If the naming is the only problem, I can fix that in a minute. > And only thing needing any renaming are these (with my proposal): > > FS_ and FL_ => FILTER_TYPE_ (IMO it's not necessary to separate these) It is, because there's both a sanitizing and validation filter for email and url. > FC_CALLBACK => `FILTER_CALLBACK` (there's just one) I changed in CVS as follows: FL_* -> FILTER_VLIDATE_* FS_* -> FILTER_SANITIZE_* (except: FS_UNSAFE_RAW to `FILTER_UNSAFE_RAW` FS_DEFAULT to `FILTER_DEFAULT` ) FC_CALLBACK -> `FILTER_CALLBACK` I also commented out the registering of all the FL and FS constants into PHP, as you should use the name of the filter and not this constant. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #21619 — Derick Rethans — 2006-01-21T12:50:00+00:00 URL: https://externals.io/message/21591#21619 · In reply to: #21608 > I am all for the filter extension as well obviously, but I agree there is a > bit of cleanup needed and I have a bunch of things I'd like to see in it, but > none of them necessarily block adding it. What would you like to add? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #21629 — Daniel Convissor — 2006-01-21T17:14:31+00:00 URL: https://externals.io/message/21591#21629 · In reply to: #21618 Howdy: > > I changed in CVS as follows: > > FL_* -> FILTER_VLIDATE_* The above is a typo here only. The CVS commit is correct. http://news.php.net/php.pecl.cvs/5003 --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #21636 — Rasmus Lerdorf — 2006-01-22T23:02:02+00:00 URL: https://externals.io/message/21591#21636 · In reply to: #21619 > > > […] > > What would you like to add? A useful tag filter that understands attributes as well so you can lock down exactly which tags with which attributes you wish to allow through. It's a non-trivial addition. -Rasmus --- Next page: https://externals.io/message/21591.md?page=2