Zend Framework 1.7 features AMF support
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 :).
Comments
Simon •
There will always be room for a solution like this that isn't owned by the Big Guys, and isn't subject to their whims.Wil Sinclair •
I agree with Simon- there's a lot of interest in AMF among PHP'ers that leaves room for more than one implementation. On the other hand, Zend_Amf is a relatively low-level component that Wade Arnold has already announced will form the base upon which AMFPHP will be written, allowing him to add extra functionality to Zend_Amf (which he also wrote) that wouldn't necessarily fit into the design goals of ZF. You could also build on top of Zend_Amf if you're concerned about re-inventing that wheel. Of course, you're always welcome to help us out in developing more features in Zend_Amf itself. :)Evert •
Thanks for the offer Wil. I should really get some experience with it before I can actually start contributing.. maybe I'll try it out for a next project.And Simon, even though I agree.. I'm just not really sure what benefit my solution will give in this space. If zend changes approach and policy; well, it would still be open source and thus anyone can fork the project =).
I'm finding that skills, knowledge and experiences are often much more important than actual lines of code.. I feel like I passed that on, and I should focus on something new again.. Little sad about all this and the fact I wasn't involved with building it in the first place, but it is probably time for me to move on and try to think of something else.. Not completely sure what I'd wanna do though..
Vincent •
Am I the only one who thinks the Zend Framework is moving into an all-you-can-eat buffet with no real namespace structure, let it be just in the name. I count 57 level-1 class packages in the Framework, some of which are no relevent to mainstream PHP development: AMF, TimeSync, Paginator, MIME, Measure, LDAP, GData, etc. All these packages are Level 1 packages, with no organization whatsoever. Why isn't GData under Service? Why isn't LDAP under a more general Authentification package?Now ZF is turning into the next PEAR. You need the obese, heavily dependent framework to make anything simple.
No wonder the function names in PHP ended up like that.
Evert •
That thought has crossed my mind as well. I do think there's a lot of value, considering the quality of the code, but its becoming more tedious to use as long as they stay away from PEAR-like packaging of individual components.SD •
Sabre AMF is a breath of fresh air when compared to it's peers. Please keep it around, even if not adding features. It is a delight to use for us simple folk who enjoy using well-suited tools for the task. Thank you :-)Evert •
Thanks ! That's really nice..I definitely plan to stay and maintain the package.. can't let the users down :)
shaun •
I fully agree with SD!I really like the simplicity and flexibility of SabreAMF. Also, it's got a cool name ;)
My only (very minor) gripe is the inclusion of the closing PHP tags.. they make me nervous!!
Evert •
thnx shaun!also, I always like the closing tag from a pure aesthetics perspective. Maybe its time to bite the bullet and get rid of them :)
Evert
shaun •
heh, yeh, I used to feel the same way. Nowadays, leaving the closing tag out gives me a warm fuzzy feeling.. hey, sometimes it's the small things :) Bite the bullet dude!iongion •
Even if i never got big bucks, you saved my job countless times, SabreAMF must be alive, it is a lightweight, clean and understandable solution useful for so many projects, that's why i decided to contribute to it, so if any of you are using drupal plus flash/flex, give the sabreamf drupal module recently added to the SabreAMF google code page a try.Cheers, and thank you Simon.
Thijs •
Evert, just wanted to set it straight that we did give you credit, you've been in the PyAMF thanks file since day 0 ;)http://pyamf.org/browser/pyamf/trunk/THANKS.txt
Cheers,
Thijs
Evert •
Ah that's actually very cool =) thnx for thatbluntcoder •
The Zend Framework doesn't have an AMF client. SabreAMF does. After running some tests, I will probably switch to SabreAMF from Zend for this purpose. Keep the project Alive.Mark