Everything

php

Home » Project » Newsgroups » php.internals » JSON inclusion in core »

JSON inclusion in core

php.internals

Rasmus Lerdorf

20 years ago

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

Marcus Börger

20 years ago

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

Omar Kilani

20 years ago

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

Pierre Joye

20 years ago

On 1/21/06, Omar Kilani <omar@rememberthemilk.com> wrote:

> 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

Andi Gutmans

20 years ago

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

Ilia A.

20 years ago

As long as the extension is licensed under the PHP License, I don't see
a problem with including in PHP 6.

Ilia

Andi Gutmans

20 years ago

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:

Jani Taskinen

20 years ago

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


On Fri, 20 Jan 2006, Andi Gutmans wrote:

Andi Gutmans

20 years ago

JSON is actually useful for real-world apps and not only for
buzzword-compliance :)

At 02:02 PM 1/20/2006, Jani Taskinen wrote:

Derick Rethans

20 years ago

On Fri, 20 Jan 2006, Andi Gutmans wrote:

> JSON is actually useful for real-world apps and not only for
> buzzword-compliance :)

But so is pecl/filter ...

Derick

Pierre Joye

20 years ago

On 1/21/06, Andi Gutmans <andi@zend.com> wrote:

> 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

Jani Taskinen

20 years ago

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


On Fri, 20 Jan 2006, Andi Gutmans wrote:

Andi Gutmans

20 years ago

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:

Rasmus Lerdorf

20 years ago

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:

Andi Gutmans

20 years ago

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

Hannes Magnusson

20 years ago

On 1/21/06, Andi Gutmans <andi@zend.com> wrote:

> 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

Jani Taskinen

20 years ago

On Fri, 20 Jan 2006, Andi Gutmans wrote:

> 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

Derick Rethans

20 years ago

On Sat, 21 Jan 2006, Jani Taskinen wrote:

> On Fri, 20 Jan 2006, Andi Gutmans wrote:
> > 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)

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

Derick Rethans

20 years ago

On Fri, 20 Jan 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.

What would you like to add?

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Rasmus Lerdorf

20 years ago

On Sat, 21 Jan 2006, Derick Rethans wrote:

> On Fri, 20 Jan 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.
>
> 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

Daniel Convissor

20 years ago

Hi Rasmus:

On Sun, Jan 22, 2006 at 03:02:02PM -0800, Rasmus Lerdorf wrote:

>
> 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

Rasmus Lerdorf

20 years ago

It's pretty simple.

string json_encode(mixed whatever)
mixed json_decode(string encoded_whatever)

It's just a serializer.

-Rasmus

Andi Gutmans wrote:

Andi Gutmans

20 years ago

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:

Rasmus Lerdorf

20 years ago

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

Andi Gutmans

20 years ago

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

Jared Williams

20 years ago

> 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.

What are the security implications of doing this?
Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or
something).

Jared

Christian Stocker

20 years ago

On 21.1.2006 13:25 Uhr, Jared Williams wrote:

>
>
>>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.
>
>
> What are the security implications of doing this?
> Creating objects based on a string from a untrusted source seems not good idea, unless can prevent tampering (with an HMAC or
> something).

AFAIK an object in JSON is just an associative array in PHP, so I don't
see the point here in implementing that in anything else than an
associative array on the PHP side.

BTW, I really like the idea having this data as $_JSON "natively" in PHP
(but having explicitly to de/serialize it by the script itself is fine, too)

chregu

--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | christian.stocker@bitflux.ch |  GPG 0x5CE1DECB

Jared Williams

20 years ago

> AFAIK an object in JSON is just an associative array in PHP,
> so I don't see the point here in implementing that in
> anything else than an associative array on the PHP side.
>

The json extension currently creates stdClass objects.

$config = '{"windowA":
{
"left": 10,
"right": 10,
"height": 100,
"width": 100
},
"windowB":
{
"left": 120,
"right": 120,
"height": 120,
"width": 120
}
}';

$a = json_decode($config);

var_dump($a);

Outputs:

object(stdClass)#1 (2) {
["windowA"]=>
object(stdClass)#2 (4) {
["left"]=>
int(10)
["right"]=>
int(10)
["height"]=>
int(100)
["width"]=>
int(100)
}
["windowB"]=>
object(stdClass)#3 (4) {
["left"]=>
int(120)
["right"]=>
int(120)
["height"]=>
int(120)
["width"]=>
int(120)
}
}


Also it'd been nice if the requirement to have name/label in double quotes was removed, (I havent read a JSON spec, so it maybe
correct) but javascript doesn't require it.

Jared

Pierre Joye

20 years ago

On Sat, 21 Jan 2006 13:30:44 -0000
jared.williams1@ntlworld.com ("Jared Williams") wrote:

> Also it'd been nice if the requirement to have name/label in double
> quotes was removed, (I havent read a JSON spec, so it maybe correct)
> but javascript doesn't require it.

It is defined this way in the JSON spec.

See this page for more details:
http://www.crockford.com/JSON/

--Pierre

Daniel Convissor

20 years ago

On Sat, Jan 21, 2006 at 02:21:14PM +0100, Christian Stocker wrote:

>
> AFAIK an object in JSON is just an associative array in PHP, so I don't
> see the point here in implementing that in anything else than an
> associative array on the PHP side.

Exactly what I was going to say.

The one thing I'd like to see change is having JSON "objects" decoded into
PHP associative arrays, not PHP objects, as is done in the current PECL
implementation.  Here's what happens now via PECL JSON:

========= script =========
<?php
echo '<pre>';

$enum = array('foo', 'bar');
$assoc = array('f' => 'foo', 'b' => 'bar');
$obj = new c;

echo "\nInitial PHP:\n";
print_r($enum);
print_r($assoc);
print_r($obj);

$pecl_enum = json_encode($enum);
$pecl_assoc = json_encode($assoc);
$pecl_obj = json_encode($obj);

echo "\nJSON encoded:\n";
echo $pecl_enum . "\n";
echo $pecl_assoc . "\n";
echo $pecl_obj . "\n";

echo "\nPHP decoded from JSON:\n";
print_r(json_decode($pecl_enum));
print_r(json_decode($pecl_assoc));
print_r(json_decode($pecl_obj));
?>


========= output =========
Initial PHP:
Array
(
[0] => foo
[1] => bar
)
Array
(
[f] => foo
[b] => bar
)
c Object
(
[f] => foo
[b] => bar
)

JSON encoded:
["foo","bar"]
{"f":"foo","b":"bar"}
{"f":"foo","b":"bar"}

PHP decoded from JSON:
Array
(
[0] => foo
[1] => bar
)
stdClass Object
(
[f] => foo
[b] => bar
)
stdClass Object
(
[f] => foo
[b] => bar
)


--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

Bart de Boer

20 years ago

Daniel Convissor wrote:

> Exactly what I was going to say.
>
> The one thing I'd like to see change is having JSON "objects" decoded into
> PHP associative arrays, not PHP objects, as is done in the current PECL
> implementation.  Here's what happens now via PECL JSON:

Maybe introduce an optional second argument "decodetype" to
json_decode() where you could pass on a constant like JSON_ARRAY or
JSON_OBJECT?

For example:

$assoc_array = json_decode($json_string, JSON_ARRAY);
$object      = json_decode($json_string, JSON_OBJECT);

However, I don't think such a feature should hold this from going into core.

Andi Gutmans

20 years ago

At 04:25 AM 1/21/2006, Jared Williams wrote:

>What are the security implications of doing this?
>Creating objects based on a string from a untrusted source seems not
>good idea, unless can prevent tampering (with an HMAC or
>something).

Well I think the right thing to do is pass an array of "allowed"
classes into json_decode() and raise an error/exception if it's not
in the list.

I think it wasn't clear to some people why this is needed.
I think enabling the seamless mapping of objects in between the
client and server is extremely useful. It'll save PHP developers from
having to unpack/pack their PHP objects into the right structures. So
basically I think there should be a way for an object to say what
it's key/value pairs are (__json_serialize_elements()?)  and during
decode() allow to map directly to classes. In both cases I think if
neither a serializing interface is implemented, nor are valid
"classes" provided to decode() it should work like today via StdClass.
I hope this is a bit more clear.
Andi

Lukas Smith

20 years ago

Andi Gutmans wrote:

> At 04:25 AM 1/21/2006, Jared Williams wrote:
>> What are the security implications of doing this?
>> Creating objects based on a string from a untrusted source seems not
>> good idea, unless can prevent tampering (with an HMAC or
>> something).
>
> Well I think the right thing to do is pass an array of "allowed" classes
> into json_decode() and raise an error/exception if it's not in the list.

Maybe we should try to come up with a common approach here for
unserialize() as well?

regards,
Lukas

Jeff Moore

20 years ago

On Jan 21, 2006, at 11:05 AM, Lukas Smith wrote:

> Maybe we should try to come up with a common approach here for
> unserialize() as well?

Along with mysql_fetch_object and its cousins?  I haven't yet looked at
the __set_state magic method from var_export, but isn't another side of
the same coin?

David

20 years ago

Andi Gutmans wrote:

> At 04:25 AM 1/21/2006, Jared Williams wrote:
>> What are the security implications of doing this?
>> Creating objects based on a string from a untrusted source seems not
>> good idea, unless can prevent tampering (with an HMAC or
>> something).
>
> Well I think the right thing to do is pass an array of "allowed" classes
> into json_decode() and raise an error/exception if it's not in the list.
>
> I think it wasn't clear to some people why this is needed.
> I think enabling the seamless mapping of objects in between the client
> and server is extremely useful. It'll save PHP developers from having to
> unpack/pack their PHP objects into the right structures. So basically I
> think there should be a way for an object to say what it's key/value
> pairs are (__json_serialize_elements()?)  and during decode() allow to
> map directly to classes. In both cases I think if neither a serializing
> interface is implemented, nor are valid "classes" provided to decode()
> it should work like today via StdClass.

Just as the classmap option for ext/soap?

Regards,

David

Jared Williams

20 years ago

>
> At 04:25 AM 1/21/2006, Jared Williams wrote:
> >What are the security implications of doing this?
> >Creating objects based on a string from a untrusted source seems not
> >good idea, unless can prevent tampering (with an HMAC or something).
>
> Well I think the right thing to do is pass an array of "allowed"
> classes into json_decode() and raise an error/exception if
> it's not in the list.

Perhaps just an interface? Like Traversable, means don't have to maintain an array.

Jared

Daniel Convissor

20 years ago

Hi Andi:

On Sat, Jan 21, 2006 at 08:01:25AM -0800, Andi Gutmans wrote:

>
> Well I think the right thing to do is pass an array of "allowed"
> classes into json_decode() and raise an error/exception if it's not
> in the list.
>
> I think it wasn't clear to some people why this is needed.
> I think enabling the seamless mapping of objects in between the
> client and server is extremely useful.

So are you proposing a JSON string like this:

var weehaw = {"f":"foo","b":"bar"};

Would get converted into a PHP object named "weehaw?"

--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

Douglas Crockford

20 years ago

> 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?

JavaScript does have a concept of an object in its prototype chain.
However, it is not captured in JSON, so the part about JSON's object
being just an associative array is correct.

It makes sense to me that JSON->PHP would produce an associate array.
Independent of that, it might be convenient to have a tool that maps
associative arrays into objects, but that is not a JSON operation.

Alan Knowles

20 years ago

I'm not sure that js->PHP is that critical (in terms of getting clever
with objects etc), doing standard HTTP GET/POST requests with urlencoded
values into $_GET/$_POST, 99% of the time is far more efficient way of
sending data to the server, and alot easier to debug.. You can also
implement the filter code on that data....

JSON in general looks far better suited to the PHP->js layer..

Regards
Alan

Douglas Crockford wrote:

Rasmus Lerdorf

20 years ago

Alan Knowles wrote:

> I'm not sure that js->PHP is that critical (in terms of getting clever
> with objects etc), doing standard HTTP GET/POST requests with urlencoded
> values into $_GET/$_POST, 99% of the time is far more efficient way of
> sending data to the server, and alot easier to debug.. You can also
> implement the filter code on that data....
>
> JSON in general looks far better suited to the PHP->js layer..

Yup, until browsers start sending JSON requests natively, I don't see
much js->PHP usage either.  PHP->js is the much more common use case at
this point.

-Rasmus

Douglas Crockford

20 years ago

> > JSON in general looks far better suited to the PHP->js layer..
>
> Yup, until browsers start sending JSON requests natively, I don't see
> much js->PHP usage either.  PHP->js is the much more common
> use case at this point.

We are working on better browser support for JSON. We are developing an
ActiveX control and a Mozilla extention for providing two-way
JSONRequest services, and we are in discussions with Mozilla.org and
Microsoft to make it standard equipment.

Jim Plush

20 years ago

From the enterprise point of view I think having the JSON extension
built into PHP will bring JSON usage to the forefront of "AJAX"
development.

I've been using Omar's extension here at McAfee with great success
lately... rolling out rich UI app prototypes. Shared Host users without
access to extensions will miss the boat and have to rely on user space
JSON classes which are much slower.

Douglas Crockford

20 years ago

> >JavaScript does have a concept of an object in its prototype chain.
> >However, it is not captured in JSON, so the part about JSON's object
> >being just an associative array is correct.
> >
> >It makes sense to me that JSON->PHP would produce an associate array.
> >Independent of that, it might be convenient to have a tool that maps
> >associative arrays into objects, but that is not a JSON operation.

> I'm not sure that js->PHP is that critical (in terms of
> getting clever
> with objects etc), doing standard HTTP GET/POST requests with
> urlencoded
> values into $_GET/$_POST, 99% of the time is far more
> efficient way of
> sending data to the server, and alot easier to debug.. You can also
> implement the filter code on that data....
>
> JSON in general looks far better suited to the PHP->js layer..

That is true at the moment. I am expecting that to change. In any case,
it makes sense that you can go in either direction.