Aral Balkan

The reports of SWX's death have been greatly exaggerated. Well, OK, the one report, that is.

I'm referring to the blog post by David Arno that asks Has Adobe just killed SWX?

David's post refers to the recent opening of the AMF format (good one, Adobe, and about time, I'd say) and the open source release of BlazeDS.

David states:

Flash-based RIA developers wanting to pass data between the client and a back-end server have had to choose between three unappealing technologies: XML/JSON, Adobe’s official remoting technologies and unofficial third party tools based on “hacking” Adobe file formats. The first suffers from serialization/ deserialization and verbose data format overheads. The second is just plain expensive (and only works with Java back-ends). The third is of dubious legality.

It's a good summary. Unfortunately, it's not accurate. Specifically, the bit about SWX being of "dubious legality".

Just to be clear, let me state this for the record: There is no doubt whatsoever about the legality of SWX, SWX RPC, SWX PHP or of any of the other implementations of SWX RPC (SWX Ruby, SWX Java, etc.)

It is actually quite unfortunate that Adobe's previously closed approach to all things Flash, including the "you can't make server products if you read the spec" clause in the Flash 8 spec, casts a shadow of doubt over products like SWX that benefit the Flash Platform instead of celebrating their contribution to the ecosystem. Well, I didn't read the SWF spec to create the AVM1 version of SWX PHP so it is not of "debious legality". Stating that SWX PHP is of "dubious legality" is nothing but FUD.

The same goes for the upcoming AVM2 version of SWX PHP that is based on the Flash 9 spec. The Flash 9 spec does not have the same server product restriction of the previous SWF specs so we are using it to create the AVM2 implementation.

David continues:

Has Adobe just killed SWX? Until today, SWX lacked (as far as I could tell) the ability to pass complex objects back and forth between server and client, but it more than made up for this by the server providing the data as native SWF files.

Unfortunately, again, the information here is just plain wrong.

The whole idea behind SWX is that you can pass complex objects back and forth between the tiers easily -- as they are passed as native data structures. When passing a complex data structure from client to server, SWX RPC encodes it in JSON format. When getting complex (and simple) data types from the server, you receive them as native ActionScript objects within a SWF. In fact, that's what SWX RPC is all about: native data -- both simple and complex.

Finally, David states:

However now that AMFPHP is fully legal and SWX remains in the legal grey zone, to me the choice between AMFPHP and SWX becomes a no-brainer. I can see no reason now to use SWX.

Again, SWX is not in a "legal grey zone" and the reasons for using SWX are the same as they have always been: simplicity.

And, as SWX contains AMFPHP as a library, you are not locked into using SWX RPC in your application. You can start out using the SWX gateway and then switch to using the AMF gateway (or JSON or one of the other gateways provided by AMFPHP) without re-writing your server-side classes. Or use both gateways if you want to: AMF for a web view, for example, and SWX for a mobile view.

And finally, remember that SWX RPC is still the only performant RPC solution for Flash Lite 2+ as remoting is not supported there. As evidenced by the entries in the latest SWX contest (one of the sponsors of which is Adobe), though, I would say that SWX use is far greater on the web than on mobile. This, as I understand from feedback on the Flash Mobile group, is due to the relative lack of Flash Lite 2/3 development in general in the real world currently.

I am personally delighted that Adobe have opened up the AMF protocol and released an open source version of FDS/LiveCycle Data Services. This is something I've been pushing them to do both privately and publicly for the longest time so I couldn't be happier. It's a big win for the Flash Platform.

Also, I'm very happy to see the progress made by Wade on AMFPHP. As I mentioned earlier, SWX PHP actually uses AMFPHP as a library and I have always supported (and continue to support) the AMFPHP project (just take a cursory glance at the web site if you need proof of that!) Heck, we'd all be calling it INFRNO if it wasn't for me!

I see AMFPHP and SWX as complimentary products. I made it a primary design decision of SWX PHP to have it be compatible with AMFPHP. I also urge other implementations of SWX RPC to maintain compatibility with the dominant open source AMF implementation on their respective platforms.

Adobe's latest move, far from killing SWX, will only strengthen the Flash Platform and all products on it, including SWX by winning us more developers.