I have blogged about meeting up with Georg, Peter, Andrey and Ulf in Frankfurt last November to discuss the mysqlnd project. What is mysqlnd you may ask? You can find an answer in the FAQ section of the newly released mysqlnd project page on mysql.com. However, for the lazy reader I will briefly say what it is about

The idea behind the mysqlnd is to leverage the PHP infrastructure in order to communicate with the MySQL server. As such it is a replacement for libmysql and just like libmysql it can be used in any PHP extension. So while currently the reference implementation is done inside ext/mysqli, it is pretty certain that ext/pdo_mysql will also make use of mysqlnd eventually.

Now why would we care? One boring, yet important aspect, is that mysqlnd will be licensed under the PHP license. So this will solve any legal concerns or hickups and its definitely a nicer solution than the FLOSS exception (Note: currently that page says the package is GPL, but that is just some automatic auto prepend thing that needs to be removed by the web team). More interestingly it means that mysqlnd will simply integrate much better into PHP. So mysqlnd will honor the memory limit settings of PHP. Speaking of memory mysqlnd will reduce copying as data does not need to be moved between some C lib and PHP anymore. With mysqlnd you can also hook into the actual communication between PHP and MySQL using stream filters. This is just the tip of the iceberg as mysqlnd will open up the possibility of many tweaks specifically directed at the needs of stateless computing platform like PHP.

One thing to note is that mysqlnd will only be available for PHP6. Speaking of PHP6 I am currently trying to get the semi official PHP6 todo up to date. Please let me know if you know of any items on the list that are completed, missing or missing. This todo list will hopefully ease planning and monitoring release management for PHP6.

I don't know why they made the decision to not support the stable PHP branch and develop code for an unstable, far from release PHP6 tree. In my eyes this makes mysqInd completely useless and as is if the discussion about its inclusion is ever raised my vote would be against its inclusion.

I don't quite understand your point here. Obviously it would be great to support PHP5 as well, but there is still a lot to do until mysqlnd is finally done and at that point PHP6 will be very close.

Furthermore this is only the initial project scope. Once the code is ready to go into the PHP CVS, there is nothing stopping anyone (including people from MySQL AB) to take this thing and backport it. So for example Yahoo is working on adding Unicode support to PHP6. At the same time they are back porting some of this into their internal PHP5 tree .. or so I have heard. So depending on how things go someone might determine that its useful enough to put in the effort to get mysqlnd into PHP5.

Anyways, I don't understand why not having a PHP5 version from day one makes mysqlnd any less interesting for PHP6. Does not sound like technical reasoning to me.

The main reason why we started with PHP6 support is the unicode support. Andrey developed different approaches to increase performance for unicode siginficantly - but we need to bench them first. No chance todo that in PHP5 (unless Andrei/Rasmus would send us the unicode backport).

From the technical standpoint there is absolutely no problem to support also PHP5, I assume less than 1 day of work.

Lucas,

PHP 6 is 2-3 years away from a point when you'd be able to call it stable and seriously consider it ready for deployment for any important (I hate to say "mission critical") situation. As such, thinking pragmatically, when developing new code you need to aim towards PHP5, since PHP4 is now in the diminishing cycle, although still used by vast majority of PHP users (85%+ by latest count).

Given how far off PHP6 is, you won't get any real testing done from the vast majority of PHP users, leaving the code largely untested. Had the focus been on PHP 5 you'd right away have a readily available pool of testers.

I think we will see a first "stable" release of PHP6 in late Q4 07 or early Q1 08. Contrary to PHP5, there is really a fundamental feature in PHP6 which is unicode support. PHP5 was mainly about making it possible to do nicer code, but it did not really add a truly technically new feature. So I think that we will probably see a fairly quick adoption rate from a fair amount of people, which should help bring the stability up more quickly. In order to get the same adoption rate as PHP5 has 2-3 years does however seem very likely.

Anyways again the point was that MySQL AB decided to write something that is not outdated all too soon. So the architecture is aimed at PHP6. Hopefully some people will have time to back port things to PHP5 ..

H Lukas, others,
architecturally mysqlnd depends only on streams, which means that it can be backported even to PHP4. mysqlnd is a library, which encapsulates most of the things mysqli or ext/mysql do. Actually to create the library I created a new extension, called mysqlnd in first place, but now named mysqlndext. It exposes the same interface (different name and without default links) as of ext/mysql and has added goodies of mysqli. The development of mysqlnd goes first throuhg this example extension, which will never see a release, and when it passes its own test the functions are integrated into mysqli. It took Georg 10-12 hours to integrate mysqlnd with mysqli it can take up to a day to have ext/mysql with mysqlnd support. Just look at the reference implementation of mysqlndext and modify the sources. mysqlnd does use some Unicode macroses, but it is not Unicode ready so far. Looking at the request for the ability of building it with PHP5 and also, that I wanted it compatible with PHP5 means that I will be quite more careful and have it possible through a define to be able to link it to PHP 5/PHP 4 (whoever is brave to use it with PHP 4). mysqlnd doesn't make use of OOP related userland code, thus will be safe to be compiled with PHP 4.

Regarding the tricks. Yes, mysqlnd uses tricks to boost performance, but no, in Unicode mode some of them won't work. Which means that in Unicode mode more memory will be allocated and more memcpy() calls will take place. Depending on how scripts use their result sets, mysqlnd can use up to 2x less memory than mysqli(libmysql) and save considerable number of memcpy() calls. The trick is to use a "hole" in MySQL's client/server protocol, which probably won't work for Unicode, even if we fetch the results with result set charset UCS-2. Well, actually there are cases when it can still be applied, but it won't be the general case.