Het Bijstere Spoor

I'm officially stopping development for my SabreAMF and Dropbox php library. I'm using neither myself anymore, which is detrimental for my interest and time I devote. So I felt like it's better to make it official.

I'm hoping for both projects they get forked and picked up by other people. I'm happy to transfer control of the sites to a different developer, if he or she can show good coding skills and some dedication. Dropbox-php has a mercurial repository so it's easy to clone / fork, and I just migrated SabreAMF from svn to git(hub).

Dropbox

Dropbox was a short ride. When the API first came out I had some projects in mind I wanted to write for it. Since there wasn't a PHP library yet, I took it upon myself to write one. My interests quickly moved to different subjects though. Bugs are there, and left unrepaired for too long. If you know of a good replacement library, post it in the comments.

SabreAMF

While the Dropbox lib is from pretty recent, SabreAMF is from somewhere early 2006. It was my first open source project, and it has been quite a ride. It's interesting to think back to where I was in life back then.

It kind of went downhill when Zend_AMF got released in late 2008. Originally I was helping the (paid) developer with the implementation, but then communication went silent. I only heard about it again when it was announced with much fanfare as the Adobe/Zend partnership.

This left me with a bit of a sour taste. The developer at the time was struggling with decoding the AMF0/3 bits, which was just released as an open spec at the time. Originally the AMF0/3 specification was closed, and as far as I know, there were no open source implementations. It took me several months of reverse engineering to figure it out exactly. This was probably also largely due to the fact that I had little experience in this field and never seen a variable width binary-encoded 29-bit integer before. So I was mostly doing it blindly (with help from the excellent Karl Von Randow and Kevin Langdon). Having a working implementation after that time felt like a great achievement.

After checking out Zend_AMF, I found that the developer didn't bother trying decoding himself, but effectively just took my design and renamed a few methods. Mind you, these were only a couple of classes, but they were the core of the project and my blood sweat and tears. I wouldn't have minded this if I could have been a part of it (which I thought I did for a bit), but it wasn't handled very decently. Since then the Zend_AMF library has greately improved, so the evidence is stowed away in much older subversion revisions.

I hope this doesn't come across bitter. I mean no harm to said developer, his perspective may well be very different from mine. I just wanted to write this out as therapy, as this has been bugging me personally for several years.

However,

I had tons of fun and learned even more. Very much a thanks to the users, and the people that helped me out in various occasions. I still believe there's room for a 'SabreAMF', as the main message I've always heard from people was that the alternatives are too heavy.

I've since then moved away from flash-work as much as possible, with the exception of the occasional feature that flash provides well, but browsers don't yet (video). If you're thinking you need an 'AMF'-like solution, I would first highly recommend to see if JSON does not already fit your needs. There are some benefits to the binary protocol, but they only tend to apply with large scale. Most people don't fit in that category. If you do, check out Zend_AMF.

9 months after the 1.2 release, I just published a long overdue release of the SabreAMF library.

The package mainly contains bugfixes. Upgrading is highly recommended.

Download

ChangeLog

Special thanks to Ionut Stoica for creating a Drupal Module, and Asbjørn Sloth Tønnesen for the bugfixes and patches. Enjoy!

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 :).

Just posted a new SabreAMF version to googlecode, containing mostly bugfixes and a few enhancements. (download). Updating is highly recommended, this release was supposed to get out a bit earlier, but I wanted to test it in a live environment for a bit first.

Changes:

• We're now throwing an SabreAMF_InvalidAMFException instead of a generic Exception in the event on a corrupt/incorrect AMF request. (contribution by: Asbjørn Sloth Tønnesen.)
• Fixed a bug in the standard Recordset object (identified by 'datafirm').
• Fixed string reference problem occuring with multiple AMF3 bodies, identified by sylvinus and fixed with help from the PyAMF team. Thanks guys!
• Fixed a bug in AMF3 integer encoding. For some small ranges you would end up with the wrong integers in PHP. The integer decoder is also a lot faster now (Fixed by Kevin Martin).
• SabreAMF_Server now allows alternative inputs than php://input (patch by Asbjørn).

Thanks guys!

A new SabreAMF release is up for grabs at the Google Code site.

This is a bugfix-only release, fixing a few issues:

• The AMF0 and AMF3 serializers did a check with is_numeric to find out if a variable is a number, this would cause problems for numeric-strings, as this function returns true there too. This has been changed to use is_float and is_int.
• There was a bug with the serialization of integers in AMF3 within certain ranges. The algorithm has been fixed by Kevin Martin.. Also, the current implementation is faster. (thanks kevin! get a site, so I can link you..).
• When onGetRemoteClass returns an incorrect value (something else than false or a string) an incorrect exception would be thrown, this is fixed as well.
• Coding standards tid-bits

Just came across a Gentoo package for SabreAMF.

I don't have any experience with gentoo, but I think this means if you want to install SabreAMF on a gentoo box, you can simply hit:

emerge SabreAMF

sweet =)

Wil wrote a pretty good introduction to using SabreAMF with flex. He's making use of the Zend autoloader to load the classes. If you're new to SabreAMF, this might be a good starting point.

He also mentions its best to set display_errors to 0, to suppress PHP errors. I personally prefer re-throw all PHP errors as exceptions using the following class:

<?php
 
    /**
     * This is a default exception wrapper for PHP errors.
     * This allows you to deal with PHP errors as exceptions (using try..catch blocks etc..)
     *
     * @uses Exception
     * @package Sabre
     * @subpackage PHP
     * @version $Id: Exception.php 733 2007-05-15 22:04:52Z evert $
     * @copyright Copyright (C) 2007 Rooftop Solutions. All rights reserved.
     * @author Evert Pot (http://www.rooftopsolutions.nl)
     */
    class Sabre_PHP_Exception extends Exception {
 
        /**
         * __construct
         *
         * @param string $message
         * @param string $code
         * @param string $file
         * @param int $line
         * @return void
         */
        function __construct($message,$code=false,$file=false,$line=false) {
 
            parent::__construct($message,$code);
            $this->file = $file;
            $this->line = $line;
 
        }
 
        /**
         * Register this class as an error handler
         * 
         * @return void
         */
        static function register() {
 
            set_error_handler(array('Sabre_PHP_Exception','handleError'));
 
        }
 
        static function unregister() {
 
            restore_error_handler();
 
        }
 
        /**
         * handleError
         *
         * @param string $code
         * @param string $message
         * @param string $file
         * @param int $line
         * @return void
         */
        static function handleError($code,$message,$file,$line) {
 
            if (!$code) return;
            throw new self($message,$code,$file,$line);
 
        }
 
    }
 
?>

Simply call Sabre_PHP_Exception::register();, and you're off..

Adobe open-sourced their FDS (Flex Data Services) product today, and along with it published the AMF3 spec (this time without NDA!).

FDS, re-branded as BlazeDS is available under a LGPL v3 license. In their press release they also mention AMFPHP a couple of times, which is great news for the PHP community, because it implies they are backing the open source implementations.

I wanted to make sure the AMF implementation in SabreAMF is correct, by checking out the official spec. The spec is not really helpful though. It only covers AMF3, and missing some of the details. I guess I'm going to have to reverse engineer the 122MB behemoth that is BlazeDS.

SabreAMF is now considered stable.. It has been tested for over a year, and no problems have been reported for a while.

I'm not totally sure where to go from here though; The original design goals have been met, documentation is written and it is well tested. Adding features for the sake of adding features doesn't seem like a good idea; so I guess this is where the project sort of halts..

I'll stick around to support and maintain it though.

Get it here. If you are running 1.0-beta4, don't bother (it's the same)

Just posted a new release candidate for SabreAMF. SabreAMF was missing proper handling of arrays with mixed string and numeric keys in the AMF3 serializer.

Google Code download page