Earlier this week, I unsubscribed from the mailing lists of a pair of Open Source projects. About two years ago when I found the projects, they involved fascinating topics in under served niches. One of those niches - the one customer/user-facing - is still there and under served, but that's not relevant in the current discussion. In reviewing the activity on the mailing list, I noticed some interesting things: activity was very high, there were some smart people involved in the discussions and there was a lot of discussion on what should be done but nothing actually getting done.

He notes that without a codebase to work from, there can't be any direction because no one knows where things are headed or what can be done to improve it. Writing up a spec to guide the development can help, but then you still have the pitfall of who should write that spec.

Microsoft has some catching up to do in terms of standards compatibility, but they are also doing some good things with this browser. They are bringing some much needed web-standards compatibility, in addition to some JavaScript performance enhancements.

Handy new features include better HTML5 support, CSS3 support, XHTML parsing, Javascript compilation and an overall trend towards a more standards-based approach that Microsoft hasn't worried about in a good while now. He also mentions the OData toolkit that lets your web applications speak the same "language" according to Microsoft's more unified specification.

Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly. "If it takes more than 15 minutes to determine what it is that you're building, the spec wasn't done properly".

He suggests that not a single line of code should be developed before the spec is completed and, since developers usually aren't the ones creating the spec, they need to have a clear, concise definition of what's expected before hand.

In the time that I have developed software, I don't know that I've ever met a developer who got excited about writing specs for anything. In fact, most developers loathe writing specs, or developing schedules of any kind. [...] Businesses need schedules to know when products will be finished and schedule things like trade shows, product launches, and write contracts with clients who need or want a particular product.

He has a few recommendations for things that could make the process a little easier including the fact that specs should not be considered documentation, that the developers should be the ones creating them and that scheduling out the development time line isn't all about the actual development.

One of the latest (sort of) crazes sweeping the net is APIs, more specifically those that leverage REST. It's really no surprise either, as consuming REST APIs is so incredibly easy… in any language. It's also incredibly easy to create them as you essentially use nothing more than an HTTP spec that has existed for ages.

He looks at what REST is - both the request and response sides - and some of the PHP code you can use to create your own service. His example defines all of the HTTP codes and uses a processRequest function to handle the incoming request. The response is pushed back out from the processResponse method and even includes an extension of the class to handle XML requests if they're POSTed.

I thought I'd share a PHP library implementing this idea by Evans and Fowler. Written for PHP5, it's a library for defining custom specifications using composition and inheritance.

He gives the example of "Person" objects with name and age properties. A search might involve looking directly at the properties to location one that's, say, younger than 35 and has a last name of Johnson. His specification class replaces this and makes it more reusable by applying things like GreaterOrEqualSpecifications and EqualSpecifications to standardize the evaluation. Then its just a quick call to the isSatisfiedBy method to check for correctness.

Today Microsoft announced a significant initiative which aims to provide the developer community with access to a large number of Microsoft protocols and file formats. [...] With Microsoft opening up their specifications under the OSP, open-source communities like Zend Framework are now able to build such solutions without fear of litigation. There are many other areas where it will benefit open-source projects including Samba (SMB), FreeTDS (SQL Server), Mono (.NET), and others...

He shares his thoughts on the winners (Microsoft themselves, Open Source community) and losers (Microsoft's competitors, Linux) on the deal and the beneficial impact he thinks it will all have on the PHP.

Because I love all things OpenID related and am an OpenID "pusher" in Europe (blame the OpenID Europe Foundation membership on Snorri Giorgetti), I'll be proposing a PHP5 implementation of OAuth to the Zend Framework (assuming no other OAuth proposal) and PEAR (PEAR because that's now the home of my OpenID For PHP library under proposal).

You can get more information about OAuth from the project's website.