David Coallier is looking for a few good men (women, children, pets who can code, etc) to join up with the PHP development group for this year's Google Summer of Code to help with the various ideas they've come up with.

Hello everyone, as mentioned a few weeks ago the most awaited Google Summer of Code is back again this year. This being said, once again the PHP Project has been accepted and we have started posting our list of ideas (http://wiki.php.net/gsoc/2008).

Some of the projects proposed include:

• PECL, website improvements and Windows Build Support
• Automatic Code Checker
• Implement Unicode into PHP 6
• Build Infrastructure and macro bindings for writing extension in D
• Rewrite the run-tests.php script
• PhD: The PHP based Docbook renderer

Be sure to check out the full list and see where you might want to get involved!

Piggybacking on a recent proposal for traits in PHP, Lukas Smith has suggested something that could help make the organization of these sorts of contributions (and their "staying power") a bit more likely to happen - an official PHP.net wiki of sorts.

As such I really like what Stefan has done with his Traits proposal. Very nicely done. [...] Right now the RFC documents are hidden away in the unwieldy mailinglist archive and Stefan's private homepage, which could disappear any day. Of course there are also the various web archives, but what would be nice to have is a PHP.net wiki.

He notes that not only would this help protect information like this from dropping off the face of the web but it might also pave the way for some other changes to be made to the language (and to provide a space where everyone can share their ideas). He specifically mentions his wants for an array_merge_replace and a change to file_exists.

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.

Padraic Brady has officially proposed a new component for the Zend Framework - one to handle the various microformat methods that have been gaining in popularity.

I've proposed Zend_Microformat on the ZF Proposal Wiki at Zend_Microformat - Padraic Brady. I've also started a proposal page for Zend_Microformat_Xfn.

He briefly explains what they are ("a collection of data encodings") and an example of their use (like the XHTML Friends Network to link social network users). You can find out more about them here.

In filtering through the mass of projects that he's collected around him, Padraic Brady has decided to cut one loose - the Zend Framework package he'd been developing to introduce YAML parsing and functionality to the framework.

I've been going through all those open source projects and cutting the dead weight. [...] One of the victims of this review has been Zend_Yaml. Earlier this morning I found an odd comment on the Zend_Translate_Yaml proposal by Thomas Weidner that he was erasing his proposal on the basis that there had been no progress on Zend_Yaml.

He's removed the proposal from the Zend Framework proposal pages after receiving an email noting that the package would not comply fully to the YAML 1.1 specification and couldn't be included. With the introduction of the Syck extension into PECL, it could support it but Padraic opted to just tell the ZF group about this functionality rather than working on the build himself.

Evert Pot has posted his latest update for the PHP-RPC spec for PHP - PHP-RPC update 4 - hopefully the last:

Unless somebody has some great feedback with stuff I overlooked - it might need some clarification and better writing here and there, but I think the general idea is there.

The api for the server class currently works the exact same as before, but support for multi-calls has been added. I also added a client class, which is helpful when you surpass the prototyping phase and you need a more decent way to interact with the service.

Details on the proposal are in the post including code for an example usage (and a multi-call use) and the official version of the latest proposal, version 0.4. This is broken out into the two sides of the proposed method - the request and the server - and how they would handle the interaction.