I’ve hesitated in the past on adding new features in amfphp to keep it as simple and compatible as possible. In particular, I have resisted adding new serializers and deserializers so that amfphp can be used with other things than just AMF and Flash. These days, JSON and XML-RPC are popular choices for creating AJAX apps. Now, AMF3 will be supported for sure in amfphp 2, and AMF0 will be as well for backwards compatibility and the thousands of apps that will continue to be made for Flash 7 and Flash 8.

So while I’m adding one new serializer and deserializer for AMF3, I figured I could as well add support for JSON and XML-RPC. The overhead would be minimal as the transition to multiple protocols would already have been done and serializing and deserializing JSON and XML-RPC is quite trivial compared to the binary AMF format, so it wouldn’t add a lote of code and the zip would probably grow by about 20k. I don’t want however for amfphp to become a kitchen sink type software and while I definitely see value in being able to create both AJAX and Flash apps from the same code, I also recognize that there a ton of other AJAX frameworks for PHP available. I also don’t want to spread amfphp too thin.

Also, many would argue that the amfphp name would not be appropriate anymore and I certainly don’t want to start the infrno fiasco all over (although, now that flickr is all the rage, infrno would have been a cool name, and infrno’s meaning, “infrno’s not Flash Remoting, no!” would make total sense… that’s a joke by the way, anyone mentioning infrno in any conversation will be given the ‘Microsoft Bob’ look).

Update: many have suggested a middle way, having it available as a plugin. That is not possible IMHO. The reason is that while JSON-Remoting is similar to Flash-Remoting, it’s not the same. JSON doesn’t have RecordSets built-in, but it would still be awesome to ‘return mysql_query’ in PHP and have it returned as an object in JavaScript (regardless of your opinion on JavaScript, you have to admit that would be pretty damn cool). Also, JSON doesn’t support batching or debug headers. Now having a way of using NetDebug::trace for javascript debugging would be fuggawesome. So I see two posibilities. One is having JSON built-in. That would mean that you would get RecordSet serializing, and NetDebug::trace would work is some way or the other. Also amfphp’s security roles would be enforced (although _authenticate would have to be called manually). It could also work in with amfphp’s SOAP proxy functionality. It would also mean that it would work with amfphp’s proposed built-in caching (which I haven’t made up my mind on yet, but that would also be fuggawesome).

The other way would be take any one of the JSON frameworks available, add some of amfphp’s dependencies, like NetDebug, Authenticate and Headers as dummy classes, and bundle it has an extra gateway. Security features (methodTable) would likely be supported, but not SOAP, RecordSet serializing or the proposed caching mechanism. NetDebug::trace support could probably be hacked in. Now what do you think?

Update 2: The more I think about it, perhaps the second way is the way to go. Basically I rename the current ‘core’ folder to ‘amf-core’. The JSON plugin would basically have a jsongateway.php file and an ‘json-core’ folder that would include its own serializers and deserializers and whatnot. The JSON serializer/deserializer would be one of the many available under the GPL.

The more I think about it, the less there really is to share between the regular amfphp and the json version, apart from the class inclusion mechanism and the security stuff. So it would probably end up being a bit of a mess of if/elses if we would integrate the two completely. I do love the idea of doing one service and having it work in a Flash client AND a js client. As for recordsets, I could start with just postgre and MySQL and people can add their own. I’m not sure how important it would be to have comprehensive recordset handling anyway, since they’re probably a bitch to deal with in JavaScript.

Update 3: I’ve spent a good couple of hours looking at JSON frameworks and all I can say is damn, AJAX people are crazy. All these frameworks mix JavaScript and PHP and make it so intertwined that it makes me sick to the stomach. I don’t get why someone would start a PHP project and not use one of the good JS libraries available instead of banging out their own.

In any case, I think I’ve decided what to do: first, use a json serializer/deserializer, most likely the PEAR one, but removing all the PEAR dependencies. Second, have it as a plugin, with a jsongateway.php and a json-core folder. Third, serialize recordsets using ‘columns’ and ‘rows’ as demonstrated in this Mochikit demo. Fourth, enforce security through the methodTable. Fifth, don’t roll out any javascript, examples will be based on a standard library, most likely MochiKit.

I think that’ll be quite different from the usual kitchen sink approach or mixed classes and servers and JavaScript libraries that take 2 hours to load and all that stuff. Clean, efficient, and cross-platform.