Het Bijstere Spoor

It just came to my attention that Zend Framework 1.7 was released, along with AMF support.

This is good news for people looking for a solid AMF implementation for PHP, because Zend with Adobe backing will likely have a lot more eyes on it, and there's a good chance this will result in a high quality implementation.

This implementation has similar design goals as SabreAMF, which begs the question how relevant SabreAMF still is. I'm not really sure myself. I sort of feel SabreAMF served its purpose well. It (mainly AMF3) has been a reference implementation for many other projects such as PyAMF, Red5, some ruby implementation which I know forgot the name of and unless I'm mistaken also AMFPHP and this very Zend_AMF.

Note that these guys never actually gave any credit ;), so I might very well be lying here.. I mainly just overheard this in the various mailing lists and from different people.

So yea, my personal goal has been to be the first open source AMF3 implementation, and build a very clean implementation people can easily drop into existing business logic. I feel I've achieved this, and its been a fun couple of years working on this, not to mention that it has helped putting my name out there, just a little bit.

I'll keep actively maintaining for the people that placed their bets on SabreAMF, recently Asbjørn Sloth Tønnesen has been helping a lot with this as well, but I'll probably start directing people to the Zend implementation for future setups.

Let me know what you guys think. Is there still value in keeping SabreAMF growing, or should it fully go to maintenance mode? Also, thanks a lot to all the people out there that submitted bug reports, patches, blogged about it or simply used it in production! This was my first open source project (hopefully not the last), and it has been a lot of fun :).

The Zend Framework has a pretty good OpenID library. I was looking for a library written for PHP5 (strict), and this seemed like a good choice..

The Zend library requires a storage backend to record and cache some of the information, and it was very easy to implement a custom one for our database layer. There's a bunch of good examples are available on the documentation page (although they were slightly outdated with the current api and did contain sql injection problems..).

The only drawback I saw was that there was a hard dependency on the Zend frameworks' Session system. I didn't want to write an adapter for our own platform, so ended up overriding the 'verify' and '_checkId' methods to simply use PHP's built-in $_SESSION array.

The odd thing was that the changes I made to the OpenId_Consumer class only set stuff in the session, but I didn't find anything that actually retrieved those values.

On a completely off-topic note, I just got my copy of High Performance MySQL, and I'm pretty excited to read it :)

I started the process to submit PHPRPC to the major frameworks. I feel like I should submit it to all the major frameworks, so I can make sure people can use PHP-RPC regardless of their framework of choice.

Besides that, it might be a good way to gather feedback or critique from the pro's.

PEAR

For PEAR I submitted it as a new PEAR2 package. PEAR2 is the upcoming next major version of PEAR, and will be PHP5-only. Much of my code (seemed) to follow PEAR2 coding standards, but the approval process will tell.

The most interesting (or weird) change I had to make the standards to include classes from within other classes. The old PEAR standards dictate:

<?php
require_once 'My/Other/Class.php';
 
?>

Which assumes PEAR and its packages are in the include_path. However, the standard for PEAR2 is:

<?php
if (!class_exists( 'My_Other_Class',true )) {
     throw new Exception('Undefined class: My_Other_Class');
}
?>

So, this means that the user of the package has to manually include all the dependencies. There is also an allfiles.php in every directory, which loads the entire package.

This allfiles.php is considered 'for beginners'. The wiki states that its also for opcode cache friendliness, but this is false (I submitted a bug report). So as a consequence of this all that using PEAR2 packages becomes a bit more harder to use for the following target audience: "Advanced developer, but doesn't want to trace each class' dependency tree"

The proposal.

Solar Framework

I opened a ticket in Solar's trac asking if its smarter to first write the Solar implementation, or first ask for approval for the contribution, because it would be good to know if Paul M. Jones hates the idea before I start.

Solar follows PEAR's old coding standards. The only annoyance here is that I need to prepend underscores to every private and protected property. (An idea that stems from the PHP4 era, where there was no property visibility).

The ticket.

Zend Framework

I haven't really started with Zend yet, the coding standards seem to be nearly the exact same as the ones I use myself (except for the change from Sabre_ to Zend_), but in order to submit code to Zend, or even propose a package you have to sign a contract first; which means I have to print, sign and scan their pdf. Sadly, the only type of paper we have in this house is rolling paper.