As Matthew Weier O'Phinney has posted, the PSR-7 PHP-FIG proposal is in the voting stages. The PSR-7 standard defines a unified interface for working with HTTP requests and responses.

As of a short bit ago, PSR-7 (meta) — HTTP Message Interfaces — is now in the voting phase! If you are a voting member of PHP-FIG, I urge you to read the specification and meta document now, and cast your vote accordingly.

I have written previously on the need for HTTP message abstractions, and also detailed how PSR-7 works. Those posts are still valid (I've kept the latter updated with all changes!). Since the review period, my sponsors and I have been looking over feedback and comments to see if any changes were needed. Fortunately, we've not found any substantive changes were really necessary; we have, however, made a few clarifications.

He clarifies some things around:

why base path concerns are not represented in the ServerRequestInterface or UriInterface

a note that UriInterface::getPath() MUST return the string "/" if the path is empty

that UriInterface implementations MUST percent-encode reserved characters in paths and query strings, per RFC 3986

why StreamableInterface is mutable, and provided guidelines to implementors and consumers regarding how and when to use writable streams

the addition of several sections to the meta documentation detailing solutions to common stream-based concerns

He also gets into a bit more detail about streams, base paths and some of the overall outcomes if the PSR-7 proposal passes (which it looks like it will so far).

If you adopt PSR-7, will you need to change your code? Almost certainly. The goal of PHP-FIG is to improve interoperability between projects, and PSRs typically attempt this via codification of what member projects are already doing.

The purpose is to specify the rules for an interoperable PHP autoloader that maps namespaces to file system paths, and that can co-exist with any other SPL registered autoloader. This would be an addition to, not a replacement for, PSR-0.

The current autoloading standard definition (PSR-0) still allows for the use of the underscore in class names to resolve to directory paths in the application's files. In this new standard, that allowance is gone, relying only on the actual namespacing to define package pathing. This "package-oriented autoloading" is set to help move PHP package development forward into a more standardized structure.

I'd like to apply for voting membership because I feel that fig is very important and that I have enough experience to make the final result better.

All of the votes from current members have been "+1" for the project's inclusion into the standards group including ones from several other well-known projects (like Zend Framework, PEAR and Doctrine).

Phil Sturgeon has a new post about some of the progress the PHP-FIG is making (the PHP framework interoperability group) and how some of the more recently proposed standards...and a workflow he thinks can help keep things from fading like they are now.

For the last two years the ML has been chock full of different discussions about potential PSRs that could be worked on. [...] This to me is the central point of the PHP-FIG as by defining these standards it can stop the need to build 6 different damn adapter classes for your composer package if you want it to work with Buzz, Guzzle, Zend HTTP, Curl, Whatever). [...] It became apparent to me that the PHP-FIG wasn't going to get all that far as things stood. I actually saw quite a few problems with the workflow.

To try to help resolve these problems, Phil has proposed a bylaw that aims to help (and has since been voted in as part of the process). The flow has several steps that a PSR proposal has to go through, all tracked by co-sponsors, one being the main coordinator. It goes through a pre-draft, draft, review and acceptance phases. There's also some points in there about attribution, the use of the voting protocol and the flow of the voting process.

PHPClasses.org has posted the latest episode (#34) of their "Lately in PHP" podcast series. In this episode they talk about the current PHP voting process for features and a possibly better one that was proposed.

This was one of the main topics discussed by Manuel Lemos and Cesar Rodas on the episode 34 of the Lately in PHP podcast. They also discussed about the latest PHP releases, updating PHP with minimized downtime, as well how brilliant are some developers for creating pure PHP components that overcome PHP limitations without upgrading to a newer PHP version.

With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

As is mentioned in this new post to PHPMaster.com, the PHP standards group is officially in the voting process on two new standards (PSR-0 being the first) setting up some standard development practices for PHP applications - PSR-1 and PSR-2.

They initially started out as one proposal but the initial round of voting didn’t yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.

According to this new post on the Zend Developer Zone, the voting state of the Packt 2010 Open Source Awards has officially started and you can cast your vote in one of many categories (and maybe win a prize for your efforts).