I had high hopes for the group. It was the culmination of something I've been ruminating on for almost a decade (see post number 12 on my blog, dated to January 2004, for proof). My thoughts have mainly been around coding standards and best practices, helping educate developers around their benefits, and how to leverage both in order to create maintainable code.

He talks about some of the things he sees as shortfalls of the group including the definition of some of the standards (and interface structure), the current thoughts of changing of said standards and some of the "discussion" that happens in the group via the mailing lists and pull requests. He mentions that there were several times that the same discussions would happen all over again, despite people saying it had, and is tired of it.

I have better things to do with my time, things I want to create, software I want to support, hobbies and interests I want to pursue. Debating brace placement, tabs vs spaces (for the umpteenth time), or whether or not annotations have a place in programming in a dynamic language? Not so much.

The main goal is to allow libraries to receive a PsrLogLoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The implementation of this structure into your application makes it easier should you decide to swap out logging tools or want to create your own that can be used across several different frameworks. This is the third PSR to be accepted by the group, following PSR-1 and PSR-2 more related to coding standards.

A little over a year ago, there was a new push by a number of folks wanting to do more. Paul Jones did a remarkable job of spearheading the next two standards, which centered around coding style. [...] And this is when we started seeing proposals surface for shared interfaces, first around caching, and now around logging (though the latter is the first up for vote).

He talks a bit about shared interfaces - what they are and what kind of problem they aim to solve - and how he's not sure he "buys into them". He notes that "sharing is good, developing solutions is better" and stresses making it easier to operate with each other and not worry so much about standardized interfaces.

He's found a few problems with the concepts behind them like the Not Invented Here (NIH) idea they promote and that there's not really just a single solution to these kinds of problems ("space for multiple implementations"). He suggests an alternative to the idea of these shared interfaces - bridges/adapters. He illustrates this idea with some code showing the implementation of a "CacheInterface" and a "FrameworkACache" adapter that wraps the functionality of a "CacheItem" class that might be internal to your application already.

The FIG stands for Framework Interoperability Group. The name until recently was "PHP Standards Group" but this was somewhat inaccurate of the intentions of the group. [...] The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we're very aware that the rest of the PHP community is watching.

The FAQ answers other questions about the standards the group has agreed on (passed) so far, who the members of the group are, how to get involved and how framework communities can get involved.

Earlier today, the PHP Framework Interoperability Group accepted two standards recommendations. [...] There's been a lot of commentary about these proposals over the past two weeks, some of it positive and some of it negative.

He includes links to some of the commentary that's been made about the standards recently, and spends some time responding to some of the negative comments specifically, like:

• What the hell is the "PHP Standards" group? I've never heard of it before now.
• Why are you guys so secretive and closed?
• So once I join the list, I can vote on PHP-FIG Standards Recommendations? Sweet!
• Whatever. I don't need you guys telling me what to do. If I don't want to follow your so-called "standards" then you can't make me.

Anthony, whose views always make good reading, raises concerns about the way in which this group generates standards. He contrasts the current approach to RFC 2026 which defines the IETF's Internet Standards Process. [...] Where Anthony's arguments seemingly fall flat is that the FIG is not the IETF. The Framework Interoperability Group was founded to allow cooperating members to develop shared standards. It does not claim to be PHP's standards body and so there is no obligation for any PHP programmer to adopt their standards (unless they work on a member project obviously!).

He points out that the standards group's process has been slowly opening more and more ("by inches") and that the group, while made of up individuals, is more than just a collection of people - it's representatives for well-known Open Source projects.

In other words, the FIG is actually something really really good for PHP. PHP needs standards so we can make interoperability between various frameworks and applications a true reality. The hodgepodge of APIs and standards we've relied on to this point only serve to reinforce PHP's NIH obsession. [...] What the FIG should do, in my opinion, is clearly define its purpose and better document its bylaws/processes. [...] It really all comes down to better communication and pushing the community engage with the FIG.

Among the group, Paul Jones has been writing serveral proposals under the PSR-1 standard banner that include:

• The basic draft of the standard
• An extended draft of the same
• A more advanced version, PSR-2 that also includes some survey results on various syntax elements.

If you want to know more about the PHP-FIG group, you should listen to this excellent panel interview of the group from the Voices of the ElePHPant podcast. Paul and others get into the point of the group and how the standards are progressing.

The good reason for not being that active on my blog lately is the fact that I'm producing content for Microsoft's Interoperability team. Have you ever wanted to start working with Windows Azure and PHP? No idea where to start? Meet the official portal: Developing Applications for Azure with PHP.

He also links to a few specific resources that are cover Azure+Eclipse, the Azure SDK, using the Queue and using blob storage.

This morning I came across this article on PHPDeveloper.org: Blast from the Past - One Year Ago in PHP. That brief look into the past got me to thinking about what Microsoft has done lately toward PHP interoperability. (By "lately", I mean in the last few years.) And, I've been working on a presentation for TechEd in Berlin next month that will, in part, provide a brief overview of Microsoft's efforts toward PHP interoperability and support. So, I thought I'd share a bit of that summary here

The timeline runs from back in 2006 when PHP and Windows/IIS/SQL Server just wasn't much of an option through the FastCGI and SQL Server driver years and finally rounding out with WinCache, PHP 5.3 improvements for Windows and the Azure SDK for PHP.

To be honest, I was a little worried about the conference -- many see Symfony and ZF as being in competition, and that there would be no cross-pollination. I'm hoping that between Fabien, Stefan, and myself, we helped dispel that myth this week. The fact of the matter is that no single project can be fully comprehensive, and do everything perfectly.

He talks a bit more about the real difference between most of the MVC frameworks out there (tooling and communities) and each framework's development goals. Matthew's goal was to show Symfony developers that it's not just about staying within the ecosystem of your selected framework when developing - you need to branch out and find the right tool for the job. Sometimes that's found in the Zend Framework, other times it's elsewhere.