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
It should be OK provided that the forked library is still functional
when built outside of PHP; the PHP bundled version must be identical
to the version that doesn't require PHP, otherwise the PHP extension
becomes a derivative work and subject to the viral part of the
license.
I think we're good
On Sat, 21 Jan 2006 16:02:17 +1100
[EMAIL PROTECTED] (Omar Kilani) wrote:
> I'll try, but I've never spoken to the json-c developers. The project
> looked abandoned when I was doing this stuff a year ago, so I forked
> it.
Did you contact them? If they agree to change the license to a BSD-like
l
> 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<-->PH
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 anoth
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 Reth
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 pl
> 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":
On Sat, 21 Jan 2006 13:30:44 -
[EMAIL PROTECTED] ("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
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 "allo
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 p
On Sat, 21 Jan 2006, Andi Gutmans wrote:
> Yep, I think you're right.
> It's always easier when it's not in the core because then it's clear that
> you're just linking. So I think if as long as we make sure not to touch the
> library unless Omer rolls a new independent version we should be fine.
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 p
Yep, I think you're right.
It's always easier when it's not in the core because then it's clear
that you're just linking. So I think if as long as we make sure not
to touch the library unless Omer rolls a new independent version we
should be fine.
At 02:29 AM 1/21/2006, Wez Furlong wrote:
It
>
> 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
Howdy:
On Sat, Jan 21, 2006 at 01:48:54PM +0100, Derick Rethans wrote:
>
> 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
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 coi
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'
18 matches
Mail list logo
