The Future of AMFPHP
AMFPHP has had a long run at being the preeminent choice for connecting the Flash Player to PHP. It’s design goal of being quick to install and implement, low foot print, convention over configuration, and not being a framework are what has made it great for beginner to intermediate users. Moving forward AMFPHP will exist to meet these exact same demands. However there will be one major change the core of AMFPHP will be built from the Zend Framework AMF library which is being maintained be myself and the rest of the Zend Framework community. AMFPHP will have an additional code base that continues to make it simple for beginner to intermediate developers to start working. That is really the only difference in functionality.
Let’s face it if you were trying to use AMFPHP in an enterprise capacity it did not meet your needs. Development has stagnated due to antiquated code that was based on PHP4. It made it hard for everybody to try and make any changes or additions. When Adobe contacted me about adding the AMF protocol to the Zend Framework I was excited as I had already started the difficult process of scraping the entire code base of AMFPHP and starting over.
The goal of the core AMF functionality that will be used between the two branches will have the following goals.
- Implement as much of the AMF protocol as possible in PHP
- Be fast as hell and then try and go faster
- Zero Bugs
- 85% or greater unit test code coverage
- Zend Framework coding standards
- Cleanly Licensed w/ New BSD License
- Support the AMFEXT pecl extension.
The design goals of the Zend Framework implementation of the AMF specification are quite different than AMFPHP as it is designed to be:
- A tool that easily allows Flex and Flash developers to leverage the Zend Framework.
- Highly Customizable (already frustrating to some)
- Portable to be added to other Frameworks.
Moving forward AMFPHP will continue to support it’s driving goals of being quick to install and configure and support the large existing install base.
An AMFPHP 2.0 release is dependent on these remaining additions:
- Service browser support
- Resource set for database results.
- AMFEXT support will not initial be support due to bugs that I need to fix in the extension.
If you believe that I am fragmenting the AMF for php code base then I did not explain the scenario. We are basically wrapping the same core with two different sets of classes for really two different types of end users. AMFPHP will be a fantastic fit for beginner to intermediate developers and when you need the horse power of a framework check out what I feel is the best one on the market Zend Framework.
In summery:
Need your clients IP or some database information into Flash/Flex in the next 15 minutes; AMFPHP is your friend.
If you’re going to change the world with an application that is enterprise ready and can leverage the wealth of code in a robust framework then check out Zend Framework. It may be a little more work at first but in the end you will be saying wow that is nice!
ALSO: There is no such thing is ZendAMF. I have seen this on some blog posts. There is the Zend Framework with the amf protocol server implementation using the package Zend_Amf and the class Zend_Amf_Server.
Do you mean that AMFPHP 2.0 will be based on the same core as the Zend Framework implementation of the AMF specification, that is, a completely rewritten code-base that is not compatible with PHP4? Or are you referring to the release after?
Can we at least call it Zend_AMF? “Zend Framework with the amf protocol server implementation” is a mouthful. Not super accurate especially if we are using it as a standalone or integrated in another framework.
I guess I don’t care what you call it.
Hi, Wade, When amfphp 2.0 will be released?
Xu
@Xu I would like to have it released before I go to adobe max in a week.
@darren there will not be support for php4 in AMFPHP 2.0. You will have to use the 1.9 version.
Thanks Wade. That’s fine by me – PHP4 should die already. The last time I looked at the code for AMFPHP1.9 there seemed a lot of bloat in there, and things done the old-fashioned way, just to support PHP4 so I’m glad this been removed.
Well done on this project and thanks for all your time.
sweet! will i be able to just swap out an existing installation of amfphp with the new version?
oh and please don’t worry too much about amfext right now. it’s cool and all but i think any time spent on that is too much time away from the other two.
Hi Wade,
Zend Framework 1.7.0 Preview Release requires PHP version 5.1.4 minimum. It will be the same requirement of AMFPHP 2.0?
Thanks
@Riccardo yes because we are taking advantage of DataTime for passing date objects.
@flashape that is correct. We may have to do a little work if you heavily use the VO class. We will see what the community says is critical.
Will/is the new amfphp support(ing) real type safe values ?
Everyone knows that php is untyped, but in the same time you know how much trouble one has passing database values from php to flex for example where bloody ints should be ints, floats should be numbers, dates should be dates, etc …
(Doctrine_Record for example, when using amfphp, you already have all the type info in the table, all is needed is a cast i guess, but i never could have got howto/where to write this in the amfphp code(adapter?..how does that work beside iterating…))
In this way one will not get its project polluted by dozens of factories.
when I post flex object ObjectProxy as parameter in amf function then get an error
“Uncaught exception ‘Zend_Amf_Exception’ with message ‘Unable to parse null body data flex.messaging.messages.RemotingMessage mapped class is not defined’”
how should i create mapped class for ObjectProxy?
Hello Wade;
I believe the work you’re doing in Zend_Amf is excellent. But do not think that those leaving aside the design goals of AMFPHP:
- Quick installation and implementation
- Nothing required – PHP4/PHP5 compatible, no extensions needed
- Low footprint, lightweight, fast
- Convention over configuration (service and class mapping)
- Can be embedded into a framework (see CakeAmfphp, Seagull)
- Services are “non-specific” PHP classes that are portable to anything without code change
- Productivity tools included (service browser, code gen, profiling)
- Batteries included – XML-RPC, JSON
- Not a framework by itself (use your own)
- Examples
- Mimic the AMF specification
I think that some of these goals are being ignored when they entered the Zend draft. I really think that AMFPHP can be more powerful than any other implemented in a framework.
Do not get me wrong, work in Zend_Amf is promising and with a great vision. But a different view to that of the creator of AMFPHP.
I just see comments like: “Congratulations”, “will be hoping that” and so on. I tell you: I help with AMFPHP (on everything: site, code, etc.). Only tell me what you need and how we organize ourselves. It may be a noob in team work, but I feel good in the development of PHP and AS.
PS: Excuse my poor English. I’m Mexican.
Nothing wrong with this, at all, people should get it more.
Thanks for all the hard work. Flash + PHP projects are completed much faster thanks to you.
The service browser is more valuable than you might think. We have recently switched one project from Zend to AMFPHP so that our PHP team and Flash team are independent on each other. The PHP developers are now able to complete all there requirements without having the Flash team test it for them.
So is amfphp officially done or are you still planning on releasing 2.0 someday? If amfphp development is gone forever, then do you at least plan on incorporating the service browser into ZendAMF?
Just following up on this previous question here… is AMFPHP moving toward Zend_AMF framework or is there going to be a dedicate AMFPHP release? or is this something other folks can help and get involved with?
thanks