[PHP-DEV] mysqlnd problems
Hi,
I'm trying to get working with PHP 5.3 a legacy web site designed for PHP 4.
It's working OK on PHP 5.2.9 but gives a strange error with 5.3 on Windows
and MySQL on CentOS.
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
The following is the simplest test case that can reproduce the problem on my
machine:
?php
mysql_connect('host', 'user', 'pass');
mysql_select_db('database');
I assume this has something to do with the new mysqlnd extension, but I
cannot
find how to disable it and enable the old mysql implementation in a
Windows environment
without recompiling PHP itself.
Additional info:
- PHP is running under Windows.
- MySQL server to which I'm trying to connect is on a CentOS box
- I tried connecting to my *local database* and it worked
- MySQL protocol_version is 10 on both Linux and Windows machines.
- Linux machine MySQL version is 5.0.48
- Windows machine MySQL version is 5.0.67-community-nt
Is there any other MySQL variable that I should look for?
Any feedback appreciated.
--
Ionut G. Stan
I'm under construction |http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client
Library) support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
--
http://blog.ulf-wendel.de
Artikel zu den Sun MySQL-Connectoren für PHP, C++ und OpenOffice.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
Hi,
Ionut G. Stan wrote:
Hi Ulf,
Thanks for the answer, but let me understand this better.
The old mysql API did not support the auth protocol of MySQL 4.1+, but
only lower,
while the new mysqlnd API only supports MySQL 4.1+ auth protocol. At
least this
is what I understand from the error message, your response and the note
on this page[1]
which refers specifically to PHP.
No. libmysql supports both authentication methods, versions of libmysql
4.1+. The old pre-4.1 insecure one and the new post-4.1 secure
authentication. What is different? The password hash in mysql.user is of
a different length. While with the years it has been good to have a
smooth transition, with just a recompile, I think it is high time that
the dbas should secure their systems and change the passwords. In web
environments you don't have too many users, usually just one, which will
need a new password set. Just use the statement for setting the password
and set it to the same as current, then it will work. Also, mysqlnd
doesn't work with servers which are pre-4.1. Windows developers don't
get this as download option at all - mysql 4.0 or 3.2x.x servers.
Is that true? If yes, then this should be stressed on the mysqlnd manual
page[2] so that
people can do what suits them best - update passwords or compile PHP
with the MySQL
client library. There are a lot of legacy applications using mysql_*
functions that are working
right now because the auth protocol is the old one (as in my case).
They are working either because the used libmysql is 3.23, a lpgl one,
or 4.0, because the server used is old. In the case of 4.1, 5.0 and 5.1
servers it is just laziness to change the password. It is written
somewhere in the documentation about upgrading from 4.0 to 4.1.
Sorry if I somehow missed such warnings in the manual.
There's also the problem of Windows binaries. Lots of people are
developing on Windows
and host their work where they have little control over the MySQL
configuration. People
compiling PHP on Windows are rare and even some Linux sysadmins are
afraid/don't have
the knowledge to compile PHP with special arguments (my sysadmin). In my
opinion there's
a problem right here that would have been best solved with some php.ini
setting.
On public hosting it should be very rare to get MySQL Server 4.0 or
earlier. With 4.1 and up everything is fine, just re-set your password.
Cheers,
[1] http://dev.mysql.com/doc/refman/4.1/en/old-client.html
[2] http://php.net/mysqli.mysqlnd
On 3/30/2009 11:04, Ulf Wendel wrote:
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client
Library) support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
hi,
By the way, be sure to disable the old authentification method in your
mysql config, centos forces it via a setting in my.cnf. You may also
need to update your password.
Cheers,
On Mon, Mar 30, 2009 at 10:04 AM, Ulf Wendel ulf.wen...@phpdoc.de wrote:
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot connect
to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client Library)
support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
--
http://blog.ulf-wendel.de
Artikel zu den Sun MySQL-Connectoren für PHP, C++ und OpenOffice.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
Thanks Pierre, you've, most probably, saved me some hours of desperate
searching.
On 3/30/2009 13:40, Pierre Joye wrote:
hi,
By the way, be sure to disable the old authentification method in your
mysql config, centos forces it via a setting in my.cnf. You may also
need to update your password.
Cheers,
On Mon, Mar 30, 2009 at 10:04 AM, Ulf Wendelulf.wen...@phpdoc.de wrote:
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot connect
to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client Library)
support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
--
http://blog.ulf-wendel.de
Artikel zu den Sun MySQL-Connectoren für PHP, C++ und OpenOffice.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqlnd problems
Hi Ulf,
Thanks for the answer, but let me understand this better.
The old mysql API did not support the auth protocol of MySQL 4.1+, but
only lower,
while the new mysqlnd API only supports MySQL 4.1+ auth protocol. At
least this
is what I understand from the error message, your response and the note
on this page[1]
which refers specifically to PHP.
Is that true? If yes, then this should be stressed on the mysqlnd manual
page[2] so that
people can do what suits them best - update passwords or compile PHP
with the MySQL
client library. There are a lot of legacy applications using mysql_*
functions that are working
right now because the auth protocol is the old one (as in my case).
Sorry if I somehow missed such warnings in the manual.
There's also the problem of Windows binaries. Lots of people are
developing on Windows
and host their work where they have little control over the MySQL
configuration. People
compiling PHP on Windows are rare and even some Linux sysadmins are
afraid/don't have
the knowledge to compile PHP with special arguments (my sysadmin). In my
opinion there's
a problem right here that would have been best solved with some php.ini
setting.
Cheers,
[1] http://dev.mysql.com/doc/refman/4.1/en/old-client.html
[2] http://php.net/mysqli.mysqlnd
On 3/30/2009 11:04, Ulf Wendel wrote:
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client
Library) support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net/ Num Status Summary (1381 total -- which includes 827 feature requests) ===[*Directory/Filesystem functions] 46990 Assigned Passing UTF8 strings to filesystem functions produce wrong filenames 47767 Assigned include_once does not resolve windows symlinks or junctions ===[*General Issues]== 47789 Open Opera file upload - multiple files from one input cannot be handled ===[*Network Functions]=== 47365 Open ip2long: 32bis vs. 64bit! ===[Apache2 related]== 32220 Assigned [PATCH] thread_resources for thread not getting freed when apache kills thread 47675 Open File descriptor leaked due to HAVE_BROKEN_GETCWD 47681 Open System TMP dir ignored in file uploads 47768 Open httpd ( Apache 2.2 ) crashes of abort() in signal handler ===[Arrays related]=== 46283 Open array_merge_recursive() Warning recursion detected in... 47221 Open no result from array_diff() 47836 Open array operator [] has inconsistency when the array has PHP_MAX_INT index value. ===[BC math related]== 44995 Open bcpowmod() using a scale function always returns 0 46564 Open bcmod( '1071', '357.5' ) returns '0' ===[Bzip2 Related] 29521 Assigned compress.bzip2 wrapper ===[Calendar related]= 40213 Suspended easter_date() returns wrong timestamp if ... 44474 Open GregorianToJD wrong return value ===[CGI related]== 43313 Open getopt() doesn't handle unknown parameters 45217 Open crash if -z and -m are used together 46305 Open Exception handler not invoked when using -r command line option 47042 Open php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache 47412 Open PHP_MSHUTDOWN_FUNCTION not being called under FastCGI 47540 Open CLI can go into an infinite write() loop when ignore_user_abort(true) 47605 Open PHP CGI fails to ever output HTTP 200 header 47627 Open No input file specified causing crash 47766 Feedback php-cgi.exe crashes 47825 Open POST Data being ignored ===[Class/Object related]= 45199 Assigned Serializing objects with private properties 46140 Open Unserializing with __wakeup that removes child causes subsequent refs to shift 46812 Open get_class_vars() does not include visible private variable looking at subclass 47405 Open error reports wrong file/line 47801 Open __call() accessed via parent:: operator is provided incorrect method name ===[COM related]== 31327 Assigned chinese char and word problem 32099 Assigned After opening ADO connection and closing it repeatedly, Apache stops service 34253 Assigned COM binary object/array issue (question marks?) 35875 Assigned IE event failure upon scheduling script 36360 Assigned PHP crashes when accessing an object that was just create by parent object 37562 Assigned Unable to lookup ParameterFieldDefinitions 37899 Assigned [PATCH] php_char_to _OLECHAR copies junk bytes 37965 Assigned Multi-dimensional array between PHP and COM 38719 Assigned COM Error during accessing function VirtualMachines 40424 Assigned Fatal error when setting the value of COM object's property array 40581 Assigned Pass Struct type to COM object from PHP 40664 Assigned String conversion functions wrong for multibyte chars 41055 Assigned DOTNET not instantiating fully-pathed assembly 41078 Assigned Its not possible to call Static dotNet Classes with dotnet 41189 Assigned Multi-dimensional array in COM function causes hang 41368 Assigned ADODB.Recordset ActiveConnection property - can't set with PHP 5.2.1+ 41388 Assigned Error in COM Object results 41577 Assigned DOTNET is successful once per server run 42413 Assigned Cannot iterate IE's event object 42551 Assigned new COM(HTMLFile) = warnings 42585 Assigned die() in event handler = PHP hangs 43275 Open get_class problem with COM objects 43432 Open Fatal error when setting the value of COM object's Attribute property 43470 Open COM API fails to correctly return [OUT] VT_PTR references 43506 Open com_get_active_object always fails 43521 Open Problem with Variant/Parameters 43838 Open variant_set with IE leads to hang 43897 Open $ie not cleared on IE quit 44256 Open Pb with COM in PHP5 44578 Open Strange Behavior of PHP using COM Object 45280 Open
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (78 total -- which includes 32 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[COM related]== 45836 Open cannot use com 46909 Open COM object not allowing calls to methods ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[mbstring related]= 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Open mysql_result returns nothing with blob 45246 Open make error after ./configure --with-mysql ===[ODBC related]= 39756 Open [PATCH] Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 47710 Open Undefined Index when accessing results by array ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash 47756 Open Segfault on HTML Purifier test suite ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe 47154 Open Object properties unset after setting. ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[Strings related]== 45566 Open Strict comparision on $_SERVER values fail 47691 Open strtr bug. Not replace unicode values from array, in binary string. ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input 47155 Open PHP 6.0 decodes base64 into incorrect uft-8 string 47164 Assigned uncomfortable (binary)char() append to binary string ===[URL related]== 45602 Open
Re: [PHP-DEV] mysqlnd problems
Thanks Andrey, your explanations cleared all my uncertainties.
On 3/30/2009 13:34, Andrey Hristov wrote:
Hi,
Ionut G. Stan wrote:
Hi Ulf,
Thanks for the answer, but let me understand this better.
The old mysql API did not support the auth protocol of MySQL 4.1+,
but only lower,
while the new mysqlnd API only supports MySQL 4.1+ auth protocol. At
least this
is what I understand from the error message, your response and the
note on this page[1]
which refers specifically to PHP.
No. libmysql supports both authentication methods, versions of
libmysql 4.1+. The old pre-4.1 insecure one and the new post-4.1
secure authentication. What is different? The password hash in
mysql.user is of a different length. While with the years it has been
good to have a smooth transition, with just a recompile, I think it is
high time that the dbas should secure their systems and change the
passwords. In web environments you don't have too many users, usually
just one, which will need a new password set. Just use the statement
for setting the password and set it to the same as current, then it
will work. Also, mysqlnd doesn't work with servers which are pre-4.1.
Windows developers don't get this as download option at all - mysql
4.0 or 3.2x.x servers.
Is that true? If yes, then this should be stressed on the mysqlnd
manual page[2] so that
people can do what suits them best - update passwords or compile PHP
with the MySQL
client library. There are a lot of legacy applications using mysql_*
functions that are working
right now because the auth protocol is the old one (as in my case).
They are working either because the used libmysql is 3.23, a lpgl one,
or 4.0, because the server used is old. In the case of 4.1, 5.0 and
5.1 servers it is just laziness to change the password. It is written
somewhere in the documentation about upgrading from 4.0 to 4.1.
Sorry if I somehow missed such warnings in the manual.
There's also the problem of Windows binaries. Lots of people are
developing on Windows
and host their work where they have little control over the MySQL
configuration. People
compiling PHP on Windows are rare and even some Linux sysadmins are
afraid/don't have
the knowledge to compile PHP with special arguments (my sysadmin). In
my opinion there's
a problem right here that would have been best solved with some
php.ini setting.
On public hosting it should be very rare to get MySQL Server 4.0 or
earlier. With 4.1 and up everything is fine, just re-set your password.
Cheers,
[1] http://dev.mysql.com/doc/refman/4.1/en/old-client.html
[2] http://php.net/mysqli.mysqlnd
On 3/30/2009 11:04, Ulf Wendel wrote:
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6
bytes shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on
line 18
This says everything. You cannot use old authentication with mysqlnd.
Upgrade you server passwords to the more recent and more secure
authentication method or recompile PHP with libmysql (MySQL Client
Library) support. Check ./configure --help | grep -C3 mysql and
http://www.php.net/manual/en/mysql.installation.php .
Ulf
Best,
Andrey
--
Ionut G. Stan
I'm under construction | http://igstan.blogspot.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RC2 and integer/float handling in 5.3
Hi guys, Just wanted to know if those issues are resolved? I rather not have a flow of changes in this area just before the next RC2. As a matter of fact this is the main thing that needs to get done before RC2. Other things are listed here: http://wiki.php.net/todo/php53#rc2 I would not mind being able to release RC Thursday next week. Which would mean commit freeze starting Monday next week. So how are things looking? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC2 and integer/float handling in 5.3
On Tue, Mar 31, 2009 at 12:09 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hi guys, Just wanted to know if those issues are resolved? I rather not have a flow of changes in this area just before the next RC2. As a matter of fact this is the main thing that needs to get done before RC2. Other things are listed here: http://wiki.php.net/todo/php53#rc2 I would not mind being able to release RC Thursday next week. Which would mean commit freeze starting Monday next week. So how are things looking? No chance from my side to get a commit freeze on next Monday. It is way too short sorry. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC2 and integer/float handling in 5.3
On 31.03.2009, at 00:27, Pierre Joye wrote: On Tue, Mar 31, 2009 at 12:09 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hi guys, Just wanted to know if those issues are resolved? I rather not have a flow of changes in this area just before the next RC2. As a matter of fact this is the main thing that needs to get done before RC2. Other things are listed here: http://wiki.php.net/todo/php53#rc2 I would not mind being able to release RC Thursday next week. Which would mean commit freeze starting Monday next week. So how are things looking? No chance from my side to get a commit freeze on next Monday. It is way too short sorry. Ok, then I would appreciate estimates for each item that cannot be completed until then. As soon as you can give them ... regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Removing the Zend API
Hi, I've added a new RFC to the wiki (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try and decouple the Zend engine from the libraries, in order to allow large scale changes to the Zend engine in the future. The RFC describes a prototype phase of the project, which could reasonably be done within a GSOC project, so I have added it to the GSOC 09 page (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api). If anybody has any comments, I'd be delighted to hear them. If anybody knows (or is) a good student looking for a GSOC project (and I've left it late, there are only 3 days left to apply), please encourage the student to look at this. Finally, if anybody is interested in helping mentor this as part of the GSOC, I'd be grateful for the help (I have to start writing my thesis soon). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
On 13.03.2009, at 00:39, Andrei Zmievski wrote: Christian Schneider wrote: Things gettings reserved at a later stage (like originally keywords, now namespaces) can lead to a big deal of frustration. Therefore I think it is crucial to have a clear naming guide now. And these guidelines have to be noticed by everybody who starts to use namespaces so they have to be placed prominently. Personally I'd even prefer them to be enforced in code so they can't be missed. Removing restrictions later on causes less trouble so I wouldn't mind too much if a couple of namespaces (or namespace prefixes) are reserved but never used. Just a gentle reminder to make sure we don't miss this.. So where are we at here? If nobody proposes something, this will just slide by .. I guess we can say that there is a definate risk, that eventually extensions will become namespaced. Same for internal functions. So calling a namespace Date or str is probably not a good idea .. right? Now for the less obvious stuff .. does the ZF prefix all their top level namespaces with ZF etc.? Speaking of ZF ... wasnt there an effort over at ZF to define a sensible standard? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
On Tue, Mar 31, 2009 at 12:28 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: If nobody proposes something, this will just slide by .. It seems simple enough to add a note on the manual page reserving the use of some namespaces: PHP (even if we never use it, best no-one else does) internals (ditto) SPL (reserved for SPL) PEAR (reserved for PEAR) PECL (reserved for PECL) Though we could add a simple check to the parser, I see no real need if we make this list conspicuous enough. Once the users have been warned, we are in a better position to administer their kick to the nuts. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
IMHO any extension name should be reserved as a namespace. Ilia Alshanetsky On 30-Mar-09, at 7:56 PM, Paul Biggar wrote: On Tue, Mar 31, 2009 at 12:28 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: If nobody proposes something, this will just slide by .. It seems simple enough to add a note on the manual page reserving the use of some namespaces: PHP (even if we never use it, best no-one else does) internals (ditto) SPL (reserved for SPL) PEAR (reserved for PEAR) PECL (reserved for PECL) Though we could add a simple check to the parser, I see no real need if we make this list conspicuous enough. Once the users have been warned, we are in a better position to administer their kick to the nuts. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
Lukas Kahwe Smith wrote: On 13.03.2009, at 00:39, Andrei Zmievski wrote: Christian Schneider wrote: Things gettings reserved at a later stage (like originally keywords, now namespaces) can lead to a big deal of frustration. Therefore I think it is crucial to have a clear naming guide now. And these guidelines have to be noticed by everybody who starts to use namespaces so they have to be placed prominently. Personally I'd even prefer them to be enforced in code so they can't be missed. Removing restrictions later on causes less trouble so I wouldn't mind too much if a couple of namespaces (or namespace prefixes) are reserved but never used. Just a gentle reminder to make sure we don't miss this.. So where are we at here? If nobody proposes something, this will just slide by .. I propose reserving PHP. extensions can be PHP\extname (i.e. class PHP\Phar, or for extensions with multiple levels of hierarchy PHP\PDO\mysql etc.) Alternately, we forbid namespaces in extensions, and thus users can guarantee no conflict with PHP internals simply by using them. Anything else will lead to insanity very quickly. Either we'll get wonderful conflicts or no way to figure out in advance what namespaces are OK. Ilia's suggestion of reserving any extension, current or future, as a namespace makes it impossible to predict what namespaces should not be used in userspace, and as we know, extensions can have literally any name. This, in my opinion, is no option at all, as we need to be able to know whether names we choose can be safely used with future versions of PHP. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
