Matthew Turland has posted a call to action for all of those PHP developers out there content to sit back and just request features for the language - get up and get involved!

A question that seems to be popping up more and more these days is, "When will PHP 6 be released?" It's especially annoying because the people that enjoy an exercise in futility ask this question are the same people that simply refuse to take WIR [When it's ready] for an answer. Or maybe they just read into the hype generated by trigger-happy publishers who want to preempt a stable release, I don't really know.

He points out some of the current stats - PHP 5.3's beta release date as coming to the original date, that PHP 6 code hasn't even been moved outside of CVS and the amount of work left to be done on it before its even close to being ready. This is where you come in - the internals folks contribute their time (off-hours usually) to developing the language and can only do so much:

So respect them and their time and stop asking when it's going to be ready, because they don't really know much better [about PHP6] than you do.

He also suggests two other things that you can do to keep up with the current state of development - keep your version updated and track the RFCs to see what features are being added and any bugs that might still be open for pre-release. You have to be proactive about keeping up with the current status - otherwise, you have no room to ask, over and over, "when will it be done?"

Today on the SitePoint PHP blog Troels Knak-Nielsen reminds the community about a "one-stop resource" that they can use to keep up to date on some of the latest happenings with the PHP language, the PHP.net wiki.

Since March, there has been a wiki at wiki.php.net. The most interesting section is probably wiki.php.net/rfc, which - as the name implies - contains RFC's for improvements of the language. I've rambled on about closures and lambdas before, but as you can see, there is now an accepted patch. Whether it'll make it into 5.3 is unlikely at this point, but it looks like it'll at least be coming with 5.4 and/or 6.0.

He also points out the php-internals mailing list and the summaries that Steph Fox has written up weekly about the list's latest conversations.

In a recent blog post Chris Hartjes is asking the community (more specifically the CakePHP community) for their opinions on his thoughts for a deployment method for CakePHP apps.

While I really prefer to use tools like this for deployment, I understand that not everyone wants to mess with standalone programs and configuration files. I've been asked before about Cake-specific deployment techniques, so I figure the easiest way is to see about adding a task to the Cake console.

His idea consists of two new commands - "cake deploy config" and "cake deploy" to make it simple to set up and directly deploy applications without having to go to outside software.

On the Stubbles blog, Frank Kleine has pointed out a proposal from Stefan Marr to include functionality for traits in PHP.

As a language construct within PHP it would be very easy to do the same, but easier to learn and to use. Beside some keyword issues (the RFC uses "use" as keyword, but this will of course conflict with namespaces) I'm wondering what this will have an impact on reflection - the RFC stays unclear about this.

A trait is a free-floating chink of functionality that, instead of being confined to a class (or file) that has to be called on to use it, exists where the developer can use it from anywhere at any time. This helps solve some of the issues with single inheritance in PHP.

Soenke Ruempler has posted today about something they found a need for in their group and wanted to create something they could share back with the community when it was done - a Message Queue System developed in PHP.

You'll find a Draft for a php-based messaging system below. We'd be glad if we get some comments from the readers. Because we're heavily using open source we want to give something back to the community and make the message queue system open source. And, yes, if someone is planning something like this or already knows a solution, please let us know, too. We don't wanna reinvent the wheel!

He fleshes out the proposal by describing it in three sections - the problem the need came from, some of the existing solutions the web has to offer (including the Java Message Service and IBM's XMS messaging) and the actual draft of the implementation including the architecture, scalability, a name (none yet) and where they're going from here.