Keeping It Simple

Category: php

  • Running PHP at a Windows 10 Command Line

    Running PHP at a Windows 10 Command Line

    A technical writer friend of mine asked me to help her this week. She needs to run PHP scripts at the command-line on Windows 10. She installed WAMP Server which includes PHP. I think she just needs to change the PATH so when she runs “php” in a command window, it will find the PHP interpreter.

    I hardly use Windows these days. But I do have a Windows PC around, so I tried installing WAMP, and then figuring out what it takes to change one’s PATH on Windows these days. Here are the steps, with screen shots.

    1. Open Windows Settings and click the System icon:

    2. Click the “About” link

    3. Click the “System info” link

    4. Click the “Advanced system settings” link

    5. Click the “Environment Variables…” button

    6. Select the “Path” variable and click the “Edit…” button

    7. Click the “Browse…” button

    8. Browse to the directory “C:wamp64binphpphp5.6.19” and click the “Ok” button

    9. Continue clicking the “Ok” buttons for all the windows that you opened during this exercise

    10. Open a command shell window and run “php -v” to confirm you can now use PHP via your PATH.

    Now you should be able to run PHP in the command window from any directory.

  • Webinar on PHP and MySQL Replication

    Using MySQL replication gives you an opportunity to scale out read queries. However, MySQL replication is asynchronous; the slave may fall behind.
    This Wednesday, January 23 2013, I’ll be presenting a free webinar about using MySQL replication on busy PHP web sites.  Register here:  http://www.percona.com/webinars/readwrite-splitting-mysql-and-php

    Applications have variable tolerance for data being out of sync on slaves, so we need methods for the application to query slaves only when their data are within tolerance. I describe the levels of tolerance, and give examples and methods for choosing the right tolerance level in your application. 

    This talk shows the correct ways to check when the slave is safe to query, and how to architect your PHP application to adapt dynamically when the slave is out of sync.
    I’ll also demonstrate an extension to the popular PHP Doctrine database access library, to help application developers using MySQL to make use of read slaves as effectively as possible.

    Please join me in this free webinar this Wednesday!
  • Don’t Put the Cart Before the Horse

    Don’t Put the Cart Before the Horse

    April 2nd I made this undiplomatic statement (funny how Twitter practically encourages being provocative):

    #ZF 2.0 is a great example of second-system syndrome.

    Matthew Weier O’Phinney and I have a good working relationship. I think his work on the Zend Framework project has been amazing, both from a technology perspective and a marketing perspective. 
    Matthew and Bill
    So when Matthew asked me to clarify my Tweet, I was happy to reply, in the spirit of constructive criticism. These thoughts apply to many projects–not just ZF–so I thought they would be of general interest. Here’s the content of my reply:

    When I’ve reviewed project proposals or business plans, one thing I often advise people is that you can’t describe the value of a project in terms of how you implemented it. Users don’t want to hear about how you used XML, or dependency injection, or unit tests, or agile methodology, or whatever. They want to hear what they can do with this product.

    After reading the roadmap for ZF 2.0, I observed that a great majority of the planned changes are refactoring and internal architectural changes. These are worthwhile things to do, but the roadmap says very little about the feature set, or the value to users.

    What I’m saying is that implementation does not drive requirements. That’s putting the cart before the horse.

    I admit that for a developer framework, this line is more blurry than in other products. Your users do care about the architecture more than they would for a traditional application. But that still doesn’t account for the emphasis on implementation changes in the roadmap, and the lack of specific feature objectives.

    For instance, some goals for the controller are described in a list of four bullet items: lightweight, flexible, easy to extend, and easy to create and use custom implementations (which sounds close to easy to extend). Then it jumps right into implementation plans.

    So how flexible does it need to be, and in what usage scenarios? What does lightweight mean? How will you know when it’s lightweight? Are there benchmark goals you’re hoping to meet?

    Another example is namespacing. Yes, using namespaces allows you to use shorter class names. Is that the bottleneck for users of ZF 1.x? Do you need to create a namespace for every single level of the ZF tree to solve this? Would that be the best solution to the difficulties of using ZF 1.x?

    The point is that the way to decide on a given implementation is to evaluate it against a set of requirements. You haven’t defined the requirements, or else you’ve defined the requirements in terms of a desired implementation.

    My view is that requirements and implementation are decoupled; a specific implementation should never be treated as one of the requirements, only a means of satisfying the requirements.

    Regards,
    Bill Karwin

  • Announcing Awk on Rails

    Announcing Awk on Rails

    Awk on Rails is a new kind of web application development framework, with a distinction that no other framework has: Awk on Rails is fully POSIX compliant.

    Awk on Rails brings the best practices of modern web application development to the ALAS stack (Apache, Linux, Awk, Shell). This stack is entirely new to the field of web development, yet already brings decades of maturity.

    • Installation is a breeze — in fact, it’s unnecessary, because Awk on Rails uses commands and tools already provided by your operating system.
    • Develop web applications that leverage the power of high-speed interprocess I/O pipelining, utilizing POSIX regular expressions to optimize request routing through common gateway interfaces.
    • Generate your Awk on Rails application code–using awk! A sophisticated script-based front-end called wreak takes care of it for you.
    • You get unlimited flexibility to customize the base application scripts, using your choice of development environment: vi or emacs.
    • SQL? We got NoSQL! We don’t need no stinking SQL! Tired of being confused by relational databases? Manage your data in an “X-treme” non-relational data store exclusive to Awk on Rails. It’s called Hammock, and it’s based on the POSIX key-value system NDBM. To initialize your data store, it’s as simple as running the command: wreak hammock.
    • Design and render application views using the simple and popular M4 language. We all know we need to keep application design separate and free from logic. Awk on Rails can make sure this happens!
    • Embedded source code documentation is easy using a custom macro package. Create ready-to-typeset manuals with one simple command: nroff -Mawkdoc.
    • Awk on Rails comes with example applications to get you started, including a blogging & content management platform AwkWord, and a syndication provider AWRY.
    • Does it scale? Of course! Thanks to the power of Moore’s Law, you’ll stay ahead of the curve over the long haul.
    • Development, deployment, and distribution are all powered by a convenient set of three distinct software licenses. No other framework supports this many licenses! Contributing back to the Awk on Rails project? You get to sign and submit a fourth license — at no charge!

    You will soon be able to download source for Awk on Rails and join its development community, at the social source repository SCCSHub.net. As soon as we figure out whether the licenses allow us to distribute our own source code, you may be able to use it in your projects too!

    Look for future Awk on Rails developments and announcements in 2010.* Also look for an innovative cloud computing extension to Awk on Rails, called VaporWare.

    Awk on Rails: Not Really Rapid, Not Exactly Agile, More Like Dodgy.

    * Awk on Rails comes with no guarantee of release dates or timeliness of announcements. Check your calendars.

  • Parrot Web Framework?

    Wondering if the following idea could be feasible:

    • Architect a web framework that emphasizes Inversion of Control.
    • Implement core web framework in Parrot (now that this dynamic language platform has released its 1.0).
    • Voila! A web framework that supports any language implemented for Parrot platform.
    • Developers write plugins in any language: Python, Ruby, PHP, Perl6, Lua, C, or any other language supported on Parrot.

    Although the Parrot platform is now 1.0, specific language implementations are still in various stages of development. Realistically, I would guess that it’ll be some years before the architecture above is ready for production.

  • Quantity Over Quality

    Alex Netkachov recently reported a list of micro-optimizations for PHP. Several other bloggers (Sebastian, Maggie, Pádraic) responded with appropriate messages, reminding people that proper application design usually counts more than micro-optimizations.

    They are all correct.

    When I was an intern, I emailed a C compiler developer, to ask a question that had occurred to me regarding optimization: which is faster, ++i or i++? Assuming either form will work in my case, as in the increment expression in a for() loop. His response (paraphrased):

    “By emailing me this question, you have already wasted more computing resources than you will ever save by choosing one form over the other during your entire programming career.”

    (I’m still not sure if he meant to emphasize that the performance difference between the two expressions was extremely small, or that he didn’t think very highly of my career prospects. I’ll prefer to assume the former.)

    A list of performance factoids like those listed by Alex are missing the guidance and wisdom that software developers need to judge their importance. All of the responses from other bloggers are similarly qualitative, instead of quantitative.

    I know that it’s hard to make quantitative statements with regards to optimization.

    • How much benefit can I get by replacing print with echo? It depends on how much printing you do in a given application — and also what else you’re doing in that application.
    • Can I benefit from caching page output or results of resource-consuming functions? Probably, but not if the content is 100% dynamic and must be re-calculated for each request.
    • Which of these micro-optimizations should I employ with greater priority? Which is the best use of my development time?

    These micro-optimization tips are interesting and worth knowing, but they should also be taken with a grain of salt. Their importance varies, depending on the nature of your application. There are no magic words that are guaranteed to double performance in every application.

    Finding the best way to optimize your code is your job as a software developer. You must use scientific measurement, as well as good judgment, experience, and intuition to get your job done most effectively.

  • ActiveRecord does not suck

    I’ve been reading a few blog postings such as Kore Nordmann’s ActiveRecord sucks and Mike Seth’s ActiveRecord sucks, but Kore Nordmann is wrong.

    ActiveRecord is fine.  It is a tool that does just what it’s designed to do.  What sucks is when developers try to make it do other things than what it’s intended to do.

    I worked for Zend, managing the Zend Framework project through its 1.0 release.  I also completed the implementation and documentation of Zend_Db and its related components. To set the record straight, Zend_Db does not implement the ActiveRecord pattern. It implements the Table Data Gateway and Row Data Gateway patterns, which taken together offer similar value as the ActiveRecord pattern.

    I totally agree with Mike Seth that MVC should not be taken as “ActiveRecord-View-Controller.” I tried to make this point in documentation, screencasts, conference presentations, and in many mailing list messages, but I met with little success.

    Unfortunately, the Ruby on Rails drumbeat that Models are simply database table wrappers has established momentum.  The term “Model” has (incorrectly) become synonymous in many developers’ minds with “ActiveRecord.”  Since Models by this definition are tied to database access and largely implementing various query techniques, Ruby on Rails development forces you to write a large amount of code in the controller classes that should properly be written in Model classes.

    This has a few consequences. Unit-testing controller classes becomes very complex, since that’s where the majority of your application code resides.  To test a controller class you need to mock HTTP requests, and sift through HTML output.  This is fine, but it results in more work since testing the controller class is so important and complex.  If the application code were separated into a true Model, then unit-testing the controller would simply be testing whether the HTTP request had been communicated to the Model correctly.  Testing the behavior of the Model would be much more straightforward unit-testing of a class API in isolation, requiring no mock HTTP requests or scraping HTML output.

    Also, unit-testing Rails-style Model classes is difficult, since the Model is coupled with the database.  We start to see unfortunate things like database fixtures as being necessary before you can execute the simplest tests against your Model class.  This makes testing Models time-consuming, error-prone, and run slowly.

    If developers were to separate Models and Controllers properly, and separate data access components from Models, unit-testing all of these classes could be done more simply, and with greater isolation from other classes.  This makes it easier to diagnose defects, when they occur.  Isn’t this the point of unit tests?

    A Model is a class that provides a logical component of your application domain.  Models are products of OO design, which is a development activity I see get very little attention in the developer blogosphere or the developer tools market.  Developers seem more enchanted by evangelizing their favorite code editor or debugger, or by squeezing more performance out of their database, than by mental analysis to make sure their OO architecture is modeling its application requirements well.

    A single Model class may be backed by a database table, or multiple database tables, or perhaps even no database tables.  Data persistence should be an internal implementation detail within a Model; the external API of the Model class should reflect its logical OO requirements, not the physical database structure.
    (update) What I often tell people is that the relationship between a Model and an ORM class should be “HAS-A” rather than “IS-A.”  The latter is the assumption of Rails and other frameworks who are enticed by ActiveRecord.  If the Model uses ORM objects instead of inheriting from ORM classes, then you can design the Model to contain all data and code for the domain it’s supposed to model — even if it takes multiple database tables to represent it.

    Many developers have complained that Zend Framework provides no base Model class. Of course it doesn’t provide a base Model class! That’s your job. This complaint is like saying that Microsoft Word sucks because it doesn’t provide finished documents for you.

    So I wouldn’t say ActiveRecord sucks.  I would say that people are expecting ActiveRecord to magically solve their OO design for them, in a false quest to avoid doing the design themselves.

  • PDO v2 CLA issues

    Wez Furlong posted a request for discussion regarding the future of PDO and they proposed to adopt a CLA (Contributor License Agreement) to manage contributions to the project. Some questions have come up indicating some misunderstandings about how CLA’s work.

    As you may know, I worked for about a year as the project manager of the Zend Framework. I was involved in administering the CLA process for that project and managing community contributions. I’ll describe my experiences on that project and give my understanding of the CLA issues. I must say however that I’m not a lawyer, nor have I talked to a lawyer about these issues.

    I should also say that I have been participating in the PDO v2 discussions. I was an employee of Zend when they started organizing meetings to discuss PDO v2. I have since left Zend, but I’m continuing to participate, now as a community developer. I’d really like to see the DBMS vendors get involved, because it would add a lot of much-needed developer resources to the PDO project.

    Discussions and Patches

    Questions have come up about how to apply the terms of a CLA to code patches submitted via an issue tracker, or a mailing list, or in chatrooms. Do these require that the author sign the CLA? In the Zend Framework project, the answer is yes. Otherwise that code cannot be incorporated into the project.

    If the author of a patch was not a CLA signer, we could do one of two things:

    1. Ask the author to sign the CLA and then grant that specific patch to the project retroactively. We did this on several occasions, and in general it was not a problem.

    2. Someone else writes a different, original solution for the problem for which the patch was made, and submits this new contribution under the terms of the CLA.

    The latter was often necessary anyway, because the patch author might not understand some of the code architecture, or their solution covered only some cases. For example, when I maintained Zend_Db, sometimes a patch was submitted to fix an issue in one DBMS-specific adapter class, but the issue really affected all DBMS brands. So I re-coded a new solution in the abstract superclass. Thus I did not use the contributor’s patch verbatim, but I wrote an alternative solution to address the same goal.

    Discussions, bug reports, and feature requests are not considered to be IP and thus are not subject to the terms of the CLA. This applies to talk on the issue tracker, the mailing lists, chatrooms, or IM. It also applies to face-to-face meetings, users groups, conferences, etc. Anyone can offer comments, criticisms, wishlists, etc. to the project without conflicting with the terms of the CLA.

    When describing a feature request, often the desired usage is illustrated with code. This code shows usage, not implementation, so it’s not likely to become part of the project. The CLA does not apply to this type of contribution. However, if that code showing usage becomes part of the project in the form of documentation or demo scripts, then in that case yes, the CLA would apply.

    Basically, a reasonable guideline is that if some contribution is checked into the project’s source control (CVS), then it’s subject to the terms of the CLA. This applies to code, test code, test data, docs, build scripts, README files, etc. — anything that can be copyrighted and that gets included with the project.

    In the Zend Framework project, we also require written proposals and specifications to be submitted under the terms of the CLA. These documents were not checked into source control (though one could argue that they should be), but they still required the assurance that the contributor was not violating someone else’s IP rights to that material. This seemed like a good policy for proposals and specs, since these documents often contain prototype code.

    Documentation and Tests are Subject to the CLA

    Anything that can be copyrighted is considered intellectual property (IP). If that IP becomes part of the project it must be treated similarly as code contributions. That is, the contributor must assure that this IP is something he has the right to contribute, and he’s not illicitly copying someone else’s work. The CLA often uses the term “contribution” instead of simply “code” because the terms of the CLA apply to more types of contributions than solely code.

    For example, in the Zend Framework project, everyone who is granted commit privileges to the subversion repository or to post proposals on the wiki must first sign a CLA. Even volunteers who translate the English documentation into other languages must sign a CLA.

    Later in this blog I may say “code” for simplicity, but what I say applies to all IP contributions in the project.

    The CLA Does Not Prohibit Code Reuse

    The CLA does not require that every contribution be original work. It does require that the contributor agree to contribute only IP that they have rights to. If the contributor is also the copyright holder of that work, this is relatively straightforward, but they could also be contributing non-original work if they have the permission of its owner.

    The point has been made that a CLA-governed project cannot build on other OSS code. Yes and no. In practice it’s rare to incorporate code of any significant size from a non-CLA-governed source, because most OSS projects cannot assure with certainty that all their contributions have been made in a manner compatible with a CLA. But this isn’t the fault of a CLA, it’s just a result of the organic way most OSS projects grow.

    CLA Does Not Exclude Community Involvement

    One assertion is that one needs to sign the CLA to view the PDO v2 specification. This is incorrect. The current PDO v1 spec is online now, and my understanding is that the PDO v2 spec will be open too. Similarly, speculation that one needs to sign a CLA to view the source code is false. Perhaps people are confusing CLA with the concept of an NDA.

    Some people believe that the use of a CLA blocks the community from being involved with the project, or that the work occurs in mysterious smoky rooms behind closed doors. This is also not true. Non-CLA signers can give feedback and discussion — but the actual code and other IP must be written by people who have signed a CLA.

    Here’s a hypothetical scenario: any community member can read the specification or the code and say, “I don’t like the way it handles feature X. It fails to account for case Y.” The contributor of the spec says, “okay, I’ve edited the spec with case Y in mind, does that satisfy your issue?”. Community member responds, “yes, that’s good.”

    See? The community stays involved, and their feedback is heeded. The Zend Framework is a good example. Hundreds of developers who never signed the CLA have filed bugs or feature requests in the issue tracker, or asked questions on the mailing lists.

    CLA Does Not Restrict OSS Freedom

    One assertion that has been made is that requiring a CLA opposes the spirit of free software, since it places conditions on contributions. I would point out that not everyone has commit privileges to the PHP project. Contributions are carefully vetted, discussed, reviewed. Many are flat out rejected, sometimes for subjective or inconsistent reasons. No one is complaining about this process — I’m not either. But it should be noted that PHP is not a free-for-all. There are good reasons to filter contributions for the sake of quality.

    The tradition of PHP includes an unwritten assumption that contributors grant their work freely, and do not expect compensation or to dictate special terms of use for their contribution. There’s also an assumption that contributors are not plagiarizing code or other IP. In fact, there have been some recent cases where code had to be removed or reimplemented to avoid IP conflicts. So PHP does have a commitment to respect other people’s copyrights and licenses, and to preserve clean IP in the project.

    Given that, is it such a bad thing for contributors to make their agreement with those traditions explicit? To promise that you contribute only IP that you have a right to contribute, and that you do so freely and do not expect compensation, seems very consistent with the spirit of OSS.

    Another tenet of OSS is that anyone can create derived works. It does not mean that a given project must accept contributions. The proposed PDO License permits creating derived works, and it even explicitly states that the derived work may use a different license, which in my mind supports the spirit of free software (I’m not a GPL zealot).

    CLA Does Not Make Contributors Legally Responsible

    Another assertion that has been made about the CLA is that by signing something, the contributor becomes “legally responsible” for their code. Of course you are responsible for not plagiarizing your code, but that’s true regardless of whether the project uses a CLA or not.

    The other interpretation of “legally responsible” is in regards to liability for damages if the code is defective. In fact, the CLA has a clause by which the contributor disclaims responsibility for the code. This “AS-IS” clause (the part in all-caps) is common in software licenses.

    But without a CLA, there is no such agreement between the original contributor and the project. The project itself could sue the contributor for a bug that resulted in damages (actually my understanding is that since PHP and PDO incorporate no legal entity, the project cannot initiate a lawsuit). Having a CLA between the contributor and the project makes it clear that the contributor offers no warranty for his code. Thus the contributor has more protection by using a CLA than by not using a CLA.

    CLA Does Not Protect Contributors From Being Sued

    Wouldn’t that be clever, to sign a form like that! “I hereby certify that no one can sue me.” It’s nonsense to expect a piece of paper to give this guarantee.

    Yet this is the argument some people use against CLA’s: that it doesn’t protect them from being sued if they contribute code that conflicts with someone else’s patent or copyright. People who use this objection have gotten it backwards. A CLA doesn’t protect you as a contributor from being sued — it is your agreement that you won’t sue other people who use your code.

    This is beneficial to you as a contributor because it goes both ways. There are other contributors writing code for the project. If these other contributors have also signed the CLA, they have agreed to grant their work to the project (subject to the terms of the license). They’ve stated that they won’t come back later and demand other terms for using their contribution. Any protection you get is not because you have signed the CLA, it’s because all the other contributors have signed the CLA.

    The purpose of the CLA is not to protect you if you write code that conflicts with someone else’s IP. That’s your responsibility. Keep in mind that this is no different if you contribute to a project that has no CLA process.

    CLA is Not the Commercial Vendors’ Plot to Control PHP

    This is incredibly cynical, and it doesn’t even make any business sense. The commercial DBMS vendors have demonstrated their commitment to OSS by contributing to many projects. Their interest is in making it attractive for developers using PHP to adopt their latest DBMS technology, by ensuring that their cutting-edge features are supported by PDO.

    But to do this, they need some assurance that by participating in the PDO project, they won’t become exposed to other contributions that contain “tainted” IP. It’s the job of the legal services professionals in each of these companies to protect them from such risk. I’m sure it’s fresh in their minds in the wake of the SCO-Linux controversies.

  • “Pure” mysqlnd interface feedback

    After I posted my idea about a pure PHP mysqlnd driver, I received an email from Ulf Wendel from the MySQL AB team who works on the mysqlnd driver. He told me I could post his comments since he doesn’t have a Blogger account. I’ll include his comments below in blockquotes and then I’ll comment below that.

    Ulf Wendel writes:

    What is “native”?

    PHP and the Borg[1] seem to be relatives. Whenever a real PHP hacker find a useful C library in the universe he speaks the famous words “resistance is futile”. A little later, the C library is available to PHP has become a PHP extension. This is one of the secrets of the early success of PHP: PHP is extentable. Extensions allow all the PHP drones to use the collective power of C libraries. As of today the PHP Function Reference shows 189 extensions [2]. Guess how many of them are written in C and how many of them are based on a C library…

    To make it short: with PHP you can choose between C and PHP. Same with Lua: a scripting language (Lua) and C (the language Lua is implemented in) can be mixed whenever appropriate. That’s the nature and the secret of both PHP and Lua. Whenever your coding bees hit a limitation of the simple to use scripting language you use the C level. Implementing the MySQL Client/Server Protocol[3] is such an example. It would be slow.

    Compare that to Java. Is it common to extend the Java programming language? No, not really, very few people start hacking a Java virtual machine. And once you have hacked one virtual machine, what about portability and the other virtual machines out there. Alternatives? Well, if you enjoy cross-compiling, maybe… That’s why you would never want to write a JDBC driver in any other language but Java. And, Java is more of a compiled language than PHP is, therefore it is fast enough.

    Native for PHP can mean both: C and PHP. If its C – like with mysqlnd – you have to ask what external dependencies exist. The MySQL native driver for PHP (mysqlnd) gets all the infrastructure it needs from PHP itself. The driver is part of PHP, therefore mysqlnd runs on all platforms that run PHP.

    Why using C?

    You list some disadvantages of choosing C:

    a) Platform-dependence not given

    Mysqlnd runs on all platforms that run PHP. Mysqlnd is a part of PHP, it does use in particular:

    – PHP memory management (limits really work now!)
    – PHP data structures (less copy operations and memory savings)
    – PHP Streams

    b) Communication protocol inspection not possible

    The MySQL native driver for PHP does use PHP Streams. PHP Streams feature hooks, aka Stream Filters [4]. With a little hacking you could expose the internal stream to the userland (PHP scripts). However, we favour MySQL Proxy[5] and therefore we have not implemented it.

    To sum up: technically its possible but we have not enabled it. Tell us why you need it inside PHP and you have a fair chance to see it implemented.

    Last but not least: have you ever worked on a raw binary network stream in PHP. Do your really want to know about the details of the protocol which Andrey started to love while he was implementing it? Or do you want to use something that is already there and might be the future standard: MySQL Proxy[5].

    c) Deployment problems with no access to php.ini

    First, with mysqlnd foundations have been laid to enable MySQL support by default: no license issue, no version issues, no external library dependencies. Its up to php.net and its community to decide if mysqlnd should be added to the default PHP configuration.

    Second, if you choose a hosting service that does not configure/compile PHP as you need it, you do something wrong – honestly.

    Anyway: all the above is minor stuff. The main reason is maximum integration into PHP for the best performance and easy deployment with no license issues.

    [1] http://en.wikipedia.org/wiki/Borg_%28Star_Trek%29
    [2] http://www.php.net/manual/en/funcref.php
    [3] http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol
    [4] http://www.php.net/manual/en/ref.stream.php
    [5] http://forge.mysql.com/wiki/MySQL_Proxy

    Now my comments to Ulf’s comments:

    First, thank you very much Ulf for your reply to my blog posting. I appreciate getting information “from the source” and it’s important to get more information about libmysqlnd out to the community.

    I want to reiterate that I think Libmysqlnd is the right solution for the PHP community, given the requirements of providing high-performance, quality extension with a PHP-compatible license. I look forward to libmysqlnd being part of the standard PHP distribution if the PHP community approves it.

    I’m not lobbying to change libmysqlnd! I’m just supposing that a MySQL connector written in PHP code might also be interesting, even if it were not the preferred connector for MySQL server. It would be useful in a few circumstances, and also could be a debugging tool.

    The performance advantage of C over of PHP is important. It stands to reason that an implementation of the MySQL protocol in a scripting language would be quite a bit slower.

    However, it would be interesting to try it and measure the actual difference in performance, if for no other reason than understanding exactly how much performance advantage is achieved by using C. I understand from a user’s comment that libraries exist in other scripting languages that implement the MySQL Protocol. Net::MySQL for Perl, Ruby/MySQL, and an unreleased Python library.

  • Idea for “pure” mysqlnd interface

    When I first heard about the mysqlnd project at the MySQL Camp in 2006, somehow I thought it was going to be 100% PHP code. I can’t remember now if I was making an incorrect assumption or if they planned to write it in PHP but changed their mind.

    What we have today is a DLL that is a drop-in replacement for libmysql. This has a few nice advantages. It means the replacement library will be API-compatible with all three PHP extensions for MySQL, (mysql, mysqli, and pdo_mysql) so it requires no one to change their PHP application code. The libmysqlnd is licensed under the PHP license, so it can be distributed with PHP core without any license conflict. All in all a good solution that will help both PHP and MySQL.

    But what about my (mistaken) impression of a MySQL client written in PHP, instead of implemented as a DLL? Essentially this would implement in PHP code the MySQL client/server protocol.

    It’s certainly possible that implementing this protocol in a language like PHP would be hopelessly inefficient and not suitable for any real world development. But it would have a few nice advantages:

    • Providing a platform-independent MySQL client.
    • Deploying easily in hosting environments with no access to configure php.ini.
    • Allowing PHP debugging tools to inspect at the protocol level.
    • Serving as a model for similar drivers for Perl, Ruby, Python, etc.
    • Licensing with the same license as the respective language, e.g. PHP License, Artistic License, or GPL.

    Writing a driver in the host language has precedent. A JDBC type 4 driver is supposed to implement the vendor’s client/server protocol in 100% Java code, so as to appear to the RDBMS server as indistinguishable from the vendor’s own client library.

    So for now, this is just an idle idea. Please don’t anyone ask me where to download this imaginary software, it doesn’t exist as far as I know!