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
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 stuff then
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
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
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 PROTECTED]
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
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
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 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
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 anything with
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 to
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
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
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 to
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,
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 to
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
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 characters
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
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/libtool
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 contributions,
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 this
Having a clear and transparent contribution process is much more
important to my eyes than good support for some company'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
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
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 PHP
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
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 some company'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
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 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 some company's products.
No, it is not more important. 99.9% of PHP users don't care what process
we have, they
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
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 world but no
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 some company's products.
No, it is not more important. 99.9% of PHP users don't care what process
we have, they care
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
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.
Can
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
if we want to
a onclick=process(?php echo json_encode($stringValue); ?)
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
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
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. Fortunately,
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:
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
40 matches
Mail list logo
