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.

Comments

• Hi David, Apologies if I wasn't clear on the legality issue, I was up at 3am by chance when I saw your comment and decided to reply :) To clarify: As Jens states in his comment, the SWF specification is semi-open. It is published but there are restrictions on its use. Previously these restrictions included not making a competing Flash Player and not making products that create a SWF on the server. The key point here is this though: Those restrictions only apply if you agree to Adobe's terms and read the spec. Your right to discover protocols by observation for the purpose of interoperability is legal and even protected by the DCMA in the USA. So, for the AVM1 version of SWX PHP, I wrote the SWX assembler that creates the data SWFs without ever agreeing to the terms of the Adobe license for the Flash 8 spec and without ever reading the spec. Instead, I used a trusty hex editor (0xED), Flasm, and TextMate to decipher the SWF bytecode. It took a while to do but it was fun and, most importantly, there is no legal grey zone. Starting with the spec for Flash 9, the restriction regarding server products is no longer in the license. This is why we are using the spec to create the AVM2/Flash 9 version of SWX PHP. Again, there is no legal issue here. Beyond this, I have personally spoken with a diverse range of people from within Adobe, ranging from top-level management to engineers on various teams (including the Flash Light and Flash Player teams) and they have all been very positive about SWX. Emmy even told me that the name SWX came up for consideration as a possible moniker for the the new cached components feature in Flex and that they made a conscious decision to not use it because it would clash with SWX (thanks Emmy!) :) So to reiterate one last time, there is no legal issue surrounding the use of SWX and no one at Adobe has ever given me any indication that they view it negatively. And there is no reason for them to either as it is a hugely useful addition to the Flash Platform. And, with the release of invoke.it in 2008, it's going to become even more useful. What's invoke.it? You'll see... :) (Yes, that makes a total of three secret new projects I have for 2008 and that means that my plate is officially full for the next year!) I can't wait!

  by Aral on 2007-12-14 09:30:15

• lol, I almost forgot about that whole INFRNO thing ;) I can't see any connection between BlazeDS and SWX let alone one killing the other. There was a time when I thought AMF was dying and AMFPHP one of the few projects artificially keeping it alive. I'm glad to see Adobe is picking it up again and supporting community efforts using the format. More power to SWX, I see a bright future for your project and a great market when mobile development finally takes off.

  by Peter on 2007-12-14 04:42:36

• Superb response to my post Aral, Thanks. My only point of contention is with the legality of SWX, but this may be based on a misunderstanding on my part. As I understand it, the SWX server creates SWFs on the fly. As the SWF file format is a closed proprietary format owned by Adobe and they have never released tools to support the creation of SWFs on the fly, thus SWX must be based on reverse-engineering the SWF format. Assuming the above is correct, then SWX definitely sits in a legal grey-zone as the Adobe legal team are free at any stage to stamp down on the reverse engineering of the SWF format. If I'm wrong and the tools are supplied by Adobe, then that s great news though, for that does indeed remove the legal concerns.

  by David Arno on 2007-12-14 06:56:33

• Hi David, SWF really is not a "closed proprietary format". It's rather a "published proprietary format". It is open in the sense that anyone can create software that writes SWF files, but you are not allowed to make alternatives to the Flash Player. Some do exist, but these are what you refer to as "legal grey zone". Creating SWF files has really never been a problem: http://www.flashmagazine.com/660.htm This article is from 2004 but I seem to remember that Macromedia have published the SWF spec since Flash 4 (1999/2000)? Getting to the spec used to require a license, but anyone applying will get that. It's more a formality. J

  by Jensa on 2007-12-14 09:04:37

• Oh boy .. Aral, you´re killing me. :D Time goes by so slow, if there´s that nasty thing called anticipation. :) Aside from that, I love SWX and Datum, it made my developer life a never ending piece of cake. ;)

  by Ruben Müller on 2007-12-14 18:07:11

• oh aral you are super. l want to ask a question. your web page rank is best. how old are your web site

  by fikralar on 2008-07-15 17:52:42

• Not that I'm totally impressed, but this is more than I expected when I stumpled upon a link on Digg telling that the info is quite decent. Thanks.

  by Heartburn Home Remedy on 2009-04-15 11:43:17

• Aside from that, I love SWX and Datum, it made my developer life a never ending piece of cake. ;)

  by Oyun on 2010-02-20 15:26:39