Mike Purcell has a recent post to his blog looking at the rumors of a Symfony 1.x fork and some of his own thoughts on the matter.

It's amazing that we are even having this type of discussion. We opted to use Symfony back in 0.x for some high traffic projects. [...] And now here we are on 1.4. Content and happy with the throughput the dev team is able to maintain. But now Symonfy says that 2.0 will be released and is completely different than 1.x? How is that fair to the companies, individuals, and hobbyists who have sunk time over the last four years ramping up to a point where we can take advantage of RAD (rapid app development) approach that Symfony provides?

He wonders if this same discussion will be being had years down the line when Symfony3 decides to come up on the horizon. Will there be such a major change in the architecture that developers, only a few years earlier making the major change to to Symfony2, will get burnt again?

PHPClasses.org has posted the latest episode of their "Lately In PHP" podcast series, a look at the cloud hosting PHPFog now offers including an interview with Lucas Carlson, CEO of PHPFog.

On the Lately in PHP podcast episode 13, Manuel Lemos and Ernani Joppert interview Lucas Carlson, founder and CEO of PHPFog, to tell us about the advantages of using a Cloud Hosting service that is optimized to address needs that are specific to PHP Web sites and applications. They also comment on the PHP 5.3.6 forked version released by Robert Eisele and the PHP features being voted for inclusion in version 5.4.

You can listen to this latest episode in a few different ways - either via the in-page player, by downloading the mp3 or by subscribing to their feed.

In this new post to his blog, Christian wonders if forking the 1.x branch of Symfony to create a 1.5 version is a real possibility.

The idea of forking came up. But is this really going to happen? And does it make any sense at all? What would be the benefit of forking symfony 1.4 and continuing development of the 1.x branch?

He suggests that it might be worth it because the branch is currently stable, it has a proven track record, there's already several plugins available and there's a comfort level among developers using it. He still asks the "why?" question, though:

Not switching to Symfony2 would essentially mean that you accept these flaws [in 1.x]. Now even if I don't agree I can not see a reason to argue against this. Being pragmatic is not a bad thing as such.

On the PHPClasses.org blog today Manuel Lemos gives his perspective on the recently announced PHP fork by Robert Eisele that has the community buzzing with comments from both sides of the fence.

A fork is a new version of a project that a separate group of developers that want to give the project a different route. A new PHP forked version was created by Robert Eisele to address needs that he felt were important.

He mentions the forked version as updated with the changes Robert wanted to see made and a few other concerns that have come from it. One issue is the PHP name and licensing problems and another is whether or not you should use this fork (and what its future might be).

Robert Eisele has a new post (and some new source) on his blog today that has gotten the PHP community both up in arms and excited about the potential it offers - a fork of PHP that's been modified to include lots of little improvements for changes in performance, some new PHP functions, usability improvements and changes in the MySQLi/mysqlnd drivers.

It took me a while but here's a new toy. Today I publish my own PHP fork based on the PHP 5.3.6 code base with a few changes that make the everydays developer life more bearable. It includes some of the patches I've already published about 3 years ago, my defcon extension and also my infusion extension plus a good bunch of extra gimmickries.

Updates in his release available on github) include:

• Hardcoded constants
• Turn off $_REQUEST variable if it's not needed
• new methods like str_random, ob_fwrite, sigfig and strcal
• changes in foreach, strstr and binary number handling
• updates to MySQLi/mysqlnd to return matched rows and mysqi_return

The community reaction to this fork has been divided - some think the work put into these changes should have been submitted to the main PHP project instead and others see it as a good step forward for the language. Share your thoughts by commenting on the post.

On the Zend Developer Zone Cal Evans has posted some encouragement about sharing your own thoughts about the post from Dried Buytaert about the future of PHP and Drupal.

As Dries says in his blog:

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

He points out that, in Acquia's case, there's just not enough time for the group to contribute back to the PHP project. Other posts surrounding this same discussion have also noted that there's not a good mechanism for people to "give back" to the PHP project and that getting involved requires a certain skillset that lots of developers don't have.

In a recent post Cal Evans shares his opinion on why he thinks the Drupal project should fork PHP and what benefits he sees for them in doing it.

Obviously moving the functionality [of Drupal] - not to mention the existing userbase - to a new language would be a herculean task; but what if the new language was just a version of the old. What if Drupal forked PHP and began working on its own version? With that thought in mind, I began to think hard about reasons they would want to do this. Here are the four best I came up with.

Cal list of advantages include an improved development process based on Drupal practices, the creation of a tailor made language they could tweak to just their needs, tighter integration between language and application and, of course, the ability to control the future of the language according to their needs.

In a recent post to his blog David Müller has taken a look at parallel processing in PHP using a few different methods - system calls, fork, and curl.

Since PHP does not offer native threads, we have to get creative to do parallel processing. I will introduce 3 fundamentally different concepts to emulate multithreading as good as possible.

For each of the technologies mentioned above, he provides a simple bit of sample code that does simple tasks like echoing out strings and writing to files. He also includes some benchmarks (take them with a grain of salt) of the three different methods showing how many iterations they could run through in ten seconds. He includes the benchmarking script if you'd like to try it out yourself.

According to this new post on CodeIgniter.com, EllisLab is announcing an official fork of the current CodeIgniter framework that will be driven by a group of six community members.

Yes, you read that right, EllisLab will be creating a CodeIgniter fork. For you. By you. We need six talented, opinionated, critical coders from the community who have a heavy personal and/or professional interest in CodeIgniter's ongoing development to act as deputies for the repository. [...] You can also nominate someone else for one of the six seats by emailing the above information on their behalf.

EllisLab will be going over the applications for the next few weeks and may ask the community to help them narrow things down. An NDA will have to be signed by the selected group and a rollout of this new fork is planned for sometime in Q1 of 2011.

In a new post from Brian Moon looking at how they're (DealNews) using forking in PHP applications to handle some of their Gearman processing.

While at the OReilly Open Source Convention in 2009, we were asked about how we pulled this off. So, we are releasing the two scripts that handle the forking and some instructions on how we use them. [...] These are the scripts we use to manage long running processes. They work great for us on Linux. They will not run on Windows at all. We also never had any trouble running them on Mac OS X.

The two scripts (that you can grab on their developer site) show two methods for running child processes and how to pass off requests to each one to be handled in turn.