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
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
Rasmus, Marcus,
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.
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
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
At 05:17 PM 1/20/2006, Omar Kilani wrote:
Rasmus, Marcus,
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.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
As long as the extension is licensed under the PHP License, I don't see
a problem with including in PHP 6.
Ilia
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
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:
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
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-compliantextension..
JSON is actually useful for real-world apps and not only for
buzzword-compliance :)
But so is pecl/filter ...
Derick
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
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:
yet-another-must-have-because-it-is-sexy-and-buzzword-compliantextension..
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. --JaniJSON 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..
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:
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. --JaniJSON 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..
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:
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. --JaniJSON 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..
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
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
-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: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. --JaniJSON 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..
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
Not sure about the functionality, and I agree some of it can probably way,
butWay..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)
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
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
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
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?
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
Hi Rasmus:
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.
Tags? Attributes? I can try to guess what you mean, but perhaps you can
elaborate, please?
Thanks,
--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
Hi Rasmus:
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.Tags? Attributes? I can try to guess what you mean, but perhaps you can
elaborate, please?
(X)(HT)ML would seem to be the likely candidate.
On Mon, 23 Jan 2006 11:55:26 -0500
danielc@analysisandsolutions.com (Daniel Convissor) wrote:
Hi Rasmus:
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.Tags? Attributes? I can try to guess what you mean, but perhaps you
can elaborate, please?
A "working" strip_tags, something like strip_tags_ex :)
--Pierre
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:
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
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:
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
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
At 06:01 PM 1/20/2006, Rasmus Lerdorf wrote:
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?
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