Donate | Contribute | About | Contact

Table of contents:

• What's new
• AMF Overview
• Installation
  • Check List
  • Installing AMFPHP
  • First Service
  • AMFEXT
  • Gateway.php
• Service Browser
  • Installation
  • Security
• Fundamentals
  • Security
  • Datatypes
  • Class Mapping
  • Sessions
• Creating Services
  • Getting Started
• Debugging
• Debugging primer
• PHP error logs
• Debugging proxies
  
• Tutorials
  • Strings
  • Arrays
  • Datagrid
  • Date/Time
  • Blob
  • VO's
• AMFPHP Development
  • Development Roadmap
  • SVN Access

Introduction

Today Adobe announced and released the AMF specification to the world. Sorry for being so quite (NDA) about all of this. I have been talking with Adobe about this since October and finally get to share how this will affect AMFPHP!  I have spent the day on the phone with some great tech blogs and magazines (old school blog) discussing what AMFPHP is and how it will change moving forward. I thought I would try and recap what was said so that this community received the news firsthand!

http://www.adobe.com/aboutadobe/pressroom/pressreleases/200712/121307BlazeDS.html

I had a little blob quote that was nice:

“While there are open source projects and technologies that offer remoting and messaging to Adobe Flash® and Flex client applications, the contribution of these technologies and the AMF protocol specification represents a huge step forward for standardizing implementations across multiple platforms,” said Wade Arnold with AMFPHP. “Working with Adobe, we can create a common programming model that enables RIA developers to extend the reach of their applications across different server technologies in a compatible and consistent approach. The AMFPHP project is ecstatic to be able to work directly with Adobe in order to better leverage the AMF protocol in LAMP applications.”

Based on the news today you know that there are going to be some major changes. The biggest is that there does not need to be additional effort in reverse engineering the specification. If you take the time to read through the released spec on labs and compare it to what Kevin Langdon, Karl von Randow, and Martin Schnabel have done it is amazingly close. However there are encoding  and application parts that were inherited from Java or where not a high importance that have been stumbling blocks for future AMFPHP development. The AMFPHP project is so thankful for the reverse engineering work that has been done by that team!

The goal of AMFPHP is to align its capabilities as close to that of BlazeDS as possible. So how are we going to do this?

Update serialization code in php and pecl extension

From the serialization standpoint there is not “much” of a change. In most cases there are a couple additional ways we should be handling array’s and object types. There is some optimization that we can do knowing the exact specification. These release will be consistent between the php serialization (AMFSerializer.php) and the php AMF extension.

Examples
We are going to try and use the exact examples that are distributed with Adobe LiveCycle Data Services. This should allow people that are using a different server language to easily migrate there Flex/Flash applications to AMFPHP. This should also help with the confusion as to what AMFPHP is as I commonly get questions as to what the difference is between AMFPHP and Flash Data Services. Soon I hope the response is PHP!

Error handling
The AMF specification denotes how different errors should be handled and what the response code should be. This will be added to help have a unified approach to debugging. This will also be necessary to comply with a universal service browser.

Documentation
I have started the process of documenting how to debug AMFPHP applications. This is the biggest issue with first time adopters of remoting and a big reason that people lose interest. After I have debugging documented and proper installation I hope to get to into more complex examples on some of the best practices that I have learned over the last four years of using AMFPHP.

Service Browser
The service browser will get a little more work just to finish off what was started. Patrick did an amazing job with this tool. I am trying to get Adobe to write a universal remoting browser as a plugin to eclipse. If you see anyone from the Adobe team let them know how good of an idea that sounds! Myself and many others have agree that we need a better debugger for remoting than the netconnection debugger, broser, and proxie clients. An integrated tool would save everyone lots of time.

Authentication
AMFPHP and users of AMFPHP have come up with clever ways of doing service authentication. I was about ready to release an update in November for authentication that would be specific to AMFPHP. I help off thinking that this news release was coming sooner. Now I am ready to update the authentication to match the method calls in Flex. BlazeDS leverages the Java Security Framework which is nice and not part of PHP. However we now get to see exactly how these headers are processed and responded to.

Will there be push technology?
I personally never thought that we would have C level serialization in the AMFPHP core.  AMFEXT is amazing. Push technology needs to open a persistent connection back to the client. This is something that a scripting language and a web server are not designed to do. I am not deep enough into the messaging code from BlazeDS to know exactly how this works. However I can assure you that it will be at the first thing that is added. On a side note there are a lot of ways that you can use class mapping and property change events with a polling api on the client. This is something that I hope to bring to the AMFPHP documentation.

In closing thanks Adobe! We have come a long way since the cease and desist letter from Macromedia!

Wade Arnold