On 30.11.2007 04:43, Michael Eshom wrote:
> Wish I could help, but I don't know what needs to be done or how to go
> about doing it.
That's no problem, we can show what to do =)
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
Stanislav Malyshev wrote:
>> Stas - we don't even know what they're planning to put into CVS. Just
>
> And waiting couple of days for the explanation is of course not an option.
Hi,
This is a dangerous approach Stas, the "shoot first, explain later"
approach is a closed-source model. Fortunate
if we want to
we should do
echo htmlspecialchars(json_encode($stringValue)) instead actually, and
yes JSON_HEX_TAG will help avoiding htmlspecialchars() just like
urlencode()ed data which never contains < > or so.
i'm not sure if there is problem if you put json_encode()ed data in
Wish I could help, but I don't know what needs to be done or how to go
about doing it.
Antony Dovgal wrote:
On 30.11.2007 02:51, Michael Eshom wrote:
Everything worked this time. Still get the "incompatible pointer type"
messages, but it still compiled properly. Thanks!
The incompati
You're absolutely correct that this won't save us from brain-dead
engineers, what it will save us from is broken browsers which
misinterpret otherwise legitimate data and get broken out of their
proper context. (Yes, I've seen browsers do exactly this, and you can
probably guess which versions)
To that end, the attached patch allows the caller to be paranoid about
their data and stipulate that <>&' should be encoded to hex references
instead. This doesn't stop a web developer from dropping that content
into an innerHTML of course, but it's one more rope holding the ship
together.
C
On 30.11.2007 02:51, Michael Eshom wrote:
> Everything worked this time. Still get the "incompatible pointer type"
> messages, but it still compiled properly. Thanks!
The incompatible pointer type messages are expected since ext/pgsql is not
(yet) updated to support Unicode.
And looking at the p
On Nov 29, 2007 11:56 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for 's products.
>
> No, it is not more important. 99.9% of PHP users don't care what process
> we have, they care
Everything worked this time. Still get the "incompatible pointer type"
messages, but it still compiled properly. Thanks!
Antony Dovgal wrote:
On 29.11.2007 21:11, Michael Eshom wrote:
I am unable to compile PHP6 with "--with-pgsql" on OpenSUSE 10.3. Every
time I've tried (three different sn
On 29/11/2007, Daniel Brown <[EMAIL PROTECTED]> wrote:
> On Nov 29, 2007 5:56 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > No, it is not more important. 99.9% of PHP users don't care what process
> > we have, they care about how well PHP works for them. If we had best
> > process in the wo
On Thu, 2007-11-29 at 14:56 -0800, Stanislav Malyshev wrote:
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for 's products.
>
> No, it is not more important. 99.9% of PHP users don't care what process
> we have, they care about ho
To that end, the attached patch allows the caller to be paranoid about
their data and stipulate that <>&' should be encoded to hex references
instead. This doesn't stop a web developer from dropping that content
into an innerHTML of course, but it's one more rope holding the ship
together.
C
str_replace() *can* fix the problem, but when you have a series of
nested arrays and objects, solving that problem with a separate loop
becomes onerous.
-Sara
P.S. - Sorry about the tripple post before...
Alexey Zakhlestin wrote:
is it really needed?
str_replace can easily do that…
it just
On Thu, 29 Nov 2007, Stanislav Malyshev wrote:
> > Having a clear and transparent contribution process is much more
> > important to my eyes than good support for 's products.
>
> No, it is not more important. 99.9% of PHP users don't care what process we
> have, they care about how well PHP work
Stas - we don't even know what they're planning to put into CVS. Just
And waiting couple of days for the explanation is of course not an option.
But opening up a module in the php.net CVS repository that php.net
contributors are excluded from without discussion is?
- Steph
--
PHP Interna
On Nov 29, 2007 5:56 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> No, it is not more important. 99.9% of PHP users don't care what process
> we have, they care about how well PHP works for them. If we had best
> process in the world but no support for what people need - people won't
> use PH
We welcome any and all contributions, of course, but where there are
strings attached it starts to get complicated. The problem here is that
I thought the whole purpose of CLA was to ensure there are *no* strings
attached to the contributed code.
--
Stanislav Malyshev, Zend Software Architect
Having a clear and transparent contribution process is much more
important to my eyes than good support for 's products.
No, it is not more important. 99.9% of PHP users don't care what process
we have, they care about how well PHP works for them. If we had best
process in the world but no sup
Stas - we don't even know what they're planning to put into CVS. Just
And waiting couple of days for the explanation is of course not an option.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP
On Fri, 30 Nov 2007, Rasmus Lerdorf wrote:
> It is long and complicated and I don't see how anybody could sign this
> without getting legal advice. You would also need to pass this by the
> legal department of the company you work for. Legal where I work
> wouldn't let us sign something like thi
On 29.11.2007 21:11, Michael Eshom wrote:
> I am unable to compile PHP6 with "--with-pgsql" on OpenSUSE 10.3. Every
> time I've tried (three different snapshots - the "1130" one from
> yesterday and the "1330" and "1530" snaps from today), the "make"
> process ends up dying with errors:
> /home
Richard Quadling wrote:
> The idea of a major world player contributing to our lill' old PHP
> sounds really exciting. The more the merrier, as long as the
> peer-review process works (and it seems to have kept me out of the
> core well enough!), let them come!
We welcome any and all contribution
I am unable to compile PHP6 with "--with-pgsql" on OpenSUSE 10.3. Every
time I've tried (three different snapshots - the "1130" one from
yesterday and the "1330" and "1530" snaps from today), the "make"
process ends up dying with errors:
/bin/sh /home/michael/Desktop/php6.0-200711291530/libtoo
On Nov 29, 2007, at 11:26 AM, Steph Fox wrote:
We do have peer-review after all.
Not on CLA'd code we don't.
Steph the CLA seems to just relate to the docbook xml specifications
for PDO.
Someone told you that, or have you developed psychic powers?
The same applies, regardless. If a commi
is it really needed?
str_replace can easily do that…
it just looks like this "unidentified problem" is not specific to json
On 11/29/07, Sara Golemon <[EMAIL PROTECTED]> wrote:
> While it's technically "safe" to include user supplied data in
> json_encode() serialized values. The fact that chara
Sara Golemon wrote:
> While it's technically "safe" to include user supplied data in
> json_encode() serialized values. The fact that characters such as <>&'
> remain as is means there room for some as-yet unidentified problem
> either in the browser's rendering or (more likely) elsewhere in one's
We do have peer-review after all.
Not on CLA'd code we don't.
Steph the CLA seems to just relate to the docbook xml specifications
for PDO.
Someone told you that, or have you developed psychic powers?
The same applies, regardless. If a commit to that module breaks the PHP
manual build, you
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
On 29 Nov 2007, at 7:49 PM, Steph Fox wrote:
So, what, exactly, is the fuss all about?
Richard, the problem with a CLA (moral quibbles apart) is it
prevents any of the core contributors doing anything with the code.
As in:
+# PDO Specs. CLA required to commit
+unavail||pdo-specs
That's
Hello Steph,
for example that would exclude me and I guess others as well.
marcus
Thursday, November 29, 2007, 6:49:34 PM, you wrote:
>> So, what, exactly, is the fuss all about?
> Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
> the core contributors doing anyt
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
While it's technically "safe" to include user supplied data in
json_encode() serialized values. The fact that characters such as <>&'
remain as is means there room for some as-yet unidentified problem
either in the browser's rendering or (more likely) elsewhere in one's
codebase for this data
On Nov 29, 2007 1:09 PM, David Coallier <[EMAIL PROTECTED]> wrote:
>
> On Nov 29, 2007 12:49 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > > So, what, exactly, is the fuss all about?
> >
> > Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
> > the core contributors doing
On Nov 29, 2007 12:49 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > So, what, exactly, is the fuss all about?
>
> Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
> the core contributors doing anything with the code. As in:
>
> +# PDO Specs. CLA required to commit
> +unav
So, what, exactly, is the fuss all about?
Richard, the problem with a CLA (moral quibbles apart) is it prevents any of
the core contributors doing anything with the code. As in:
+# PDO Specs. CLA required to commit
+unavail||pdo-specs
That's what 'unavail' means.
Surely all this "us/them",
On 29/11/2007, Steph Fox <[EMAIL PROTECTED]> wrote:
> > What I really don't understand is why so many people are so quick to jump
> > into "us vs. them" attitude. Is there a war or what? Isn't there enough
> > conflict so that one must look so hard to create a new one?
> > Or maybe it is worth cons
On Nov 29, 2007 5:59 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > To add to this, I think that if IBM (and others) are so keen on having
> > PHP support their nice databases, they should also realize that it is
> > them that should be nice to *us* and not the other way around. We (as in
>
What I really don't understand is why so many people are so quick to jump
into "us vs. them" attitude. Is there a war or what? Isn't there enough
conflict so that one must look so hard to create a new one?
Or maybe it is worth considering that having good database support is good
for *both* PHP
Hello Stanislav,
noone disagrees to any work any company is willing to do. Infact we should
be extremely happy about the work done by some IBM people lately (to stay
with the same company example). At least I am for one really happy! However
hiding in some secret rooms and deciding something tha
On Nov 29, 2007 12:01 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > this thread popped up. It almost seems like the beginnings of a
> > long-term hostile takeover plan, beginning quietly in the shadows.
>
> Come on... Really.
>
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PR
this thread popped up. It almost seems like the beginnings of a
long-term hostile takeover plan, beginning quietly in the shadows.
Come on... Really.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals
To add to this, I think that if IBM (and others) are so keen on having
PHP support their nice databases, they should also realize that it is
them that should be nice to *us* and not the other way around. We (as in
What I really don't understand is why so many people are so quick to
jump into
On Nov 29, 2007 6:03 AM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007, Marcus Boerger wrote:
>
> > I do not care for IBM problems. Not at all. If people want to commit
> > they can do it in their free time. If IBM now thinks they have to make
> > PHP suitable for their own stuf
On Thu, 29 Nov 2007, Marcus Boerger wrote:
> I do not care for IBM problems. Not at all. If people want to commit
> they can do it in their free time. If IBM now thinks they have to make
> PHP suitable for their own stuff then they are obviously willing to
> spend quite some interest because
Hello Daniel,
I do not care for IBM problems. Not at all. If people want to commit they
can do it in their free time. If IBM now thinks they have to make PHP
suitable for their own stuff then they are obviously willing to spend quite
some interest because they have a much bigger business interes
45 matches
Mail list logo
