Amfphp 1.1 was released just a few days ago, and already there is a new version in the works. The reason is that I think this new debug gateway greatly facilitates development and therefore we can expect more novice users to come along to amfphp and not be discouraged by debugging issues.

To this effect, the new amfphp 1.2 introduces two major changes:

• A change to the folder structure
• A major update to the service browser

The first one might seem like a crazy idea at this point since pretty much everybody is used to the standard amfphp gateway.php plus a bunch of folders setup. However, watching a French tutorial, a recommendation by the narrator really made sense to me: put gateway.php in the root folder, services in root/services and the rest in root/amf-classes. I decided to use a similar scheme for this new release, with gateway.php and debuggateway.php in the root, and three folders, services, browser and core.

The thing is, a lot of people don’t have vhosts enabled in their local webserver installation (if, in fact, they have a local webserver installed), and therefore they tend to place their swfs and html files in the same folder as gateway.php. While I can’t say that this is recommended, I can see why novices would like this no-frills install scheme. On the other hand, the slew of folders in the current scheme is useless for the average user, save for the services folder. This new scheme makes putting the files on the server simple, just upload /core and gateway.php and put whatever services you need in the services folder. Unless you guys have a better idea…

The second major change is an update to the services browser. The service browser was originally meant to ease in new users of amfphp by creating stub code for you. To that extent it has been successful. However, after seeing Fluorine’s implementation, I figured it might be time for an upgrade. So basically I copy-pasted their tree code in amfphp and voilà: classes are grouped in packages on the left hand side. It’s also much prettier. In the methodTable page there is now an option to save the methodTable to disk so you don’t have to bother to copy-paste the code.

Now the code generation has seen an overhaul with the option to save to disk directly also. This is especially handy with the new ARP stub code generation, which generates the ServiceLocator class, the Controller and a command for every remote method, placing them in the right folders, and generating the rest of the standard ARP folders while it’s at it. I’m looking at taking out AS1 and poor man’s test suite code generation and adding stub code for the new ActionStep Remoting components. Of course if you have any other brilliant ideas as to what kind of custom code should be generated feel free to share them.

Perhaps the biggest new feature is the ability to test remote methods directly in the service browser. Basically next to each method there will be a test link which brings up a test interface, which is basically a few textfields and a submit button. I am thinking allowing either ActionScript syntax (that is, 5 or “str” or {key:”val”} or [’stuff’, 5]) or PHP syntax (that is, 5 or “str” of array(”key” => val) or array(’stuff’, 5)) or both (still need feedback on that). Submitting the arguments will generate an AMF message and will call gateway.php through HTTP (using cURL), like the debug gateway currently does. Thus it will replicate exactly the behaviour of a Flash client calling amfphp, but with the distinct advantage that you don’t have to actually make a Flash movie to test your brand new service, in fact you don’t even need to know anything about Flash; this should further facilitate working with PHP programmers who are clueless about Flash (and there are quite a few of those) for larger teams.

Of course, if you have other ideas, send them my way.

Now as for amfphp 2.0, it’s still just an idea at this point, but yes, AMF3 is going to be there. Ideally I’d need a team of hackers to get working on understanding this new mysterious format. Don’t get me wrong, I think the recent decision to offer the Enterprise services server free up to a certain traffic limit is great, but installing the server in question will require getting your own dedicated server, while a vast majority of projects are deployed on shared hosting. So amfphp will still be relevant, and quite an attractive option for users looking for rapid development and low-requirements deployment options in a language everybody and their sister knows, with a ridiculously active open-source community and millions of free lines of code floating around the net for just about anything from webmail to blogs to wikis to DNA analysis to… You get the point.