Het Bijstere Spoor

For a while I've been pondering if it would be possible to build a free-for-all PEAR channel for everybody to submit their packages. I feel PHP classes kind of missed the boat here for requiring people to register to download, and well.. basically having a design that's just hard to take serious.

So since New Years, there are now 2! Yay for competition, but it's a bit sad they didn't choose to work together. I'm talking about pearfarm and pearhub.org.

Why PEAR packages?

If you publish your next opensource project as a PEAR package on a real PEAR channel, your users will be able to install PEAR packages by simply entering something like 'pear install packagename'. PEAR packages don't actually have to come from pear.php.net, but they can be hosted by any other server.

One of the benefits of getting your packages from pear.php.net, is that there is a high degree of quality control, as well as solid coding standards. I do believe though that there is a different part of the market of people who don't want to go through rigorous approval process and just want to get their stuff up for others to download. Inspired by Gemcutter; this is where pearfarm and pearhub come in.

As a bonus you'll get other fancy features PEAR provides, such as dependency management. You can easily make pear automatically download package A from author B if your package is downloaded.

What do they have in common?

Both pearfarm and pearhub are brand new, so very little packages are available. They also both seem to be a work in progress. Anybody can register for both sites and publish their packages.

Differences?

Pearfarm seems to be a more complete product, whereas Pearhub resembles the standard Pirum. Pearfarm also includes tools make it more easy to generate and upload your package and/or new releases. My biggest problem with Pearfarm is actually that it doesn't support OpenID. As a developer I'm surprised to see any code-related site being launched without OpenID support.

My pick today would be to host my packages on Pearfarm. The beauty of the PEAR system is that you don't have to choose one for downloading packages, because a package from Pearfarm can easily depend on a package from Pearhub.

Host your own

If you want to host your own pear channel, I can recommend Pirum. It's an extremely simple system that actually just generates static files. Chiara_PEAR_Server is a more complete system, but I've found it harder to customize.

Yesterday Till Klampaeckel proposed an S3 stream handler for PEAR. A great idea, as this should make integration PHP and S3 very easy.

However, it didn't take long for Cesar Rodas to respond to the proposal, claiming he was the original author of the code. Till first denied the allegations, but after Gregory Beaver presented the undeniable proof Till claimed he got the code from an intern at the company he worked with, who apparently lied about where he got the code from, and stripped out the original copyrights; violating the BSD license.

Cesar will now be credited for his code, so the issue seems somewhat resolved. This does however show a bigger problem.

If the code made it through PEAR, and was put in use in commercial applications, Cesar would have been able to claim his copyrighted code and for example sue the PHP Group or companies making use of the code. This is also exactly why any contributions to the Zend Framework requires a CLA to be signed, which effectively makes the coder responsible for only submitting code he or she owns. If a mistake such as this one would have been made, the original contributor would be liable for the legal violations, and not Zend or the entity using the code.

So the lesson of the day is, if you're going to contribute to any open source project; make absolutely sure you own the code or got explicit permission from the original author. If you don't, you can put both the open source project and the people who use your code in danger. Additionally, giving credit where its due is the decent thing to do. (and apologizing in the case you did make a mistake).

I started the process to submit PHPRPC to the major frameworks. I feel like I should submit it to all the major frameworks, so I can make sure people can use PHP-RPC regardless of their framework of choice.

Besides that, it might be a good way to gather feedback or critique from the pro's.

PEAR

For PEAR I submitted it as a new PEAR2 package. PEAR2 is the upcoming next major version of PEAR, and will be PHP5-only. Much of my code (seemed) to follow PEAR2 coding standards, but the approval process will tell.

The most interesting (or weird) change I had to make the standards to include classes from within other classes. The old PEAR standards dictate:

<?php
require_once 'My/Other/Class.php';
 
?>

Which assumes PEAR and its packages are in the include_path. However, the standard for PEAR2 is:

<?php
if (!class_exists( 'My_Other_Class',true )) {
     throw new Exception('Undefined class: My_Other_Class');
}
?>

So, this means that the user of the package has to manually include all the dependencies. There is also an allfiles.php in every directory, which loads the entire package.

This allfiles.php is considered 'for beginners'. The wiki states that its also for opcode cache friendliness, but this is false (I submitted a bug report). So as a consequence of this all that using PEAR2 packages becomes a bit more harder to use for the following target audience: "Advanced developer, but doesn't want to trace each class' dependency tree"

The proposal.

Solar Framework

I opened a ticket in Solar's trac asking if its smarter to first write the Solar implementation, or first ask for approval for the contribution, because it would be good to know if Paul M. Jones hates the idea before I start.

Solar follows PEAR's old coding standards. The only annoyance here is that I need to prepend underscores to every private and protected property. (An idea that stems from the PHP4 era, where there was no property visibility).

The ticket.

Zend Framework

I haven't really started with Zend yet, the coding standards seem to be nearly the exact same as the ones I use myself (except for the change from Sabre_ to Zend_), but in order to submit code to Zend, or even propose a package you have to sign a contract first; which means I have to print, sign and scan their pdf. Sadly, the only type of paper we have in this house is rolling paper.