Some more comments on the SWX controversy, after Aral’s rebuttal of my previous post. First off, just to be absolutely clear, I am not bashing Aral, or anybody working on SWX itself. Aral and I have have collaborated on amfphp, and are coauthors (among several other very talented people) on a new open-source Flash book, and we get along quite well, thanks ;) I’m also not saying that SWX is a stupid idea; in fact the idea behind SWX is quite clever, but the implementation is not going to yield any net benefits for the community (more on this later). As for my statement that SWX is a hack, I stand by that, and I think other people agree. But of course, you could argue that once a hack is sufficiently abstracted away in classes, it doesn’t have the disadvantages normally associated with hacks, and that makes it a valid solution. Unless I am misunderstanding Aral’s argument, I think that’s his point.

But the main advantage with SWX, as outlined by Aral, is simplicity. The code on the homepage is indeed very simple and lightweight. However, once you start abstracting away this simplicity, you’re going to end up with what is more or less a library. For example, if you wanted to be able to use SWX as you would use Remoting, using callbacks, then the abstracted code would have to: create a movieclip to absorb the loaded data, poll that thing, fire events, do cleanup. If we include batching, then it would have to set up a timer to do the job automatically. If we include RecordSet support, then there would have to be a RecordSet class in the first place, which would probably be as large as the current Remoting RecordSet class. So in the end, once SWX is sufficiently abstracted away in a library, that library which does everything Remoting does is going to be as fat as the Remoting library. So the advantage of simplicity falls through. On the server-side, once SWX starts dealing with batched calls and serializing RecordSets and the like, it’s very likely it’s going to be as fat as amfphp. So we’re going to end up, with a lot of hard work, with something completely equivalent, in size, speed, and every other variable to Remoting. Now amfphp has only now started reaching full maturity, and it’s already 3 or 4 years old. If the past is any indication as to the future, then SWX will likely take just as much time to reach the level we’ve reached in amfphp.

So my question is: if SWX will eventually do all that Remoting does in an equivalent fashion, is it worth spending all that time to do it? We’re talking about creating an AS2 abstraction layer (easy), AS3/mxml abstraction layer (harder), recordset support on the server side (simple but a pain to test), do all the testing, then there’s a discovery interface (service browser), documentation, support, and so on and so forth. It’s been a recent goal of mine to create the Universal Remoting group, which is aimed at reducing duplication of code and documentation across Remoting projects to get less bugs and better products that work equivalently on every platform. One of the main goals is to create a Flex 2 based service browser that will work across (so far) amfphp, SabreAMF, AMFRUBY and Fluorine. The Flash community has traditionally been balkanized into various equivalent projects where some die off, some survive, and a lot of time and effort is wasted in between. I think Aral has done a great job of letting projects talk to each other and get themselves known with OSFlash. But I don’t want to see the community fragment and duplicate effort over several equivalent projects.

Aral has done some very nice work with the Flex SWX call inspector (or whatever it’s called), and I’d definitely like to see that work with Remoting to replace the old NetConnection debugger. Similarly, having a simpler abstraction layer for Remoting in AS2 for smaller apps would be great; if someone wants to take a stab at that, please do. But duplicating efforts is going to get us nowhere. As Lorenz in the wonderful book On Agression argued, while competition between different animal species yields positive evolution, intra-species competition yields net negative evolution, at the cost of survival for everyone.