When I first announced SWX, Patrick Mineault, lead developer of AMFPHP, questioned whether SWX was reinventing the wheel. Why, he asked, do we need SWX when there is AMFPHP? (AMFPHP is a PHP implementation of a Flash Remoting gateway).
To start with, comparing SWX and AMFPHP is like comparing apples and oranges. As I stated earlier, SWX is a new data format for Flash and SWX RPC is a remote procedure call protocol encoded in SWX. As such, we can compare SWX to AMF (the data format) and SWX RCP to Flash Remoting (the RPC protocol) and SWX PHP (my PHP implementation of SWX RPC) to AMF PHP.
So the real question becomes, does the Flash Platform need a new data format and a new RPC protocol? I believe it does and here are some reasons why:
- Existing formats are non-native, complicated, require parsing and/or writing plumbing code e.g., XML, variable-encoded strings (LoadVars, loadVariables), Flash Remoting, etc.
- SWX files have low processor overhead when parsed by the Flash Player as they are native (SWF bytecode)
- SWX RPC is the only RPC solution for Flash Lite 2.0 and 2.1 (and thus for mobile Flash applications). Flash Remoting does not work with Flash Lite.
- Most important: SWX, being native, has inherent advantages such as cross-platform data exchange (via allowDomain support for SWF files), simplicity (no ActionScript library is necessary to use it, although there is a high-level library if you want to use it), etc.
It's my first belief that every platform can benefit from a native data format that does not require parsing. The main advantage of SWX over other data formats and of SWX RPC over other RPC solutions is ease of use. I hope that this ease of use will spur a wealth of development of data-driven applications and mashups on the Flash Platform by developers who may traditionally have shied away from creating such applications because it was just too darn hard to do so.
Utterly pointless, non-typed garbage. There is no need or use for another data format. The fact that your using your presentation to sell this atrocity is pathetic. See if it gets turned into a standard (it wont)
Don’t hold back now, do tell me how you really feel
(By the way, I removed the link in the URL you provided as it led to a spam site. I don’t believe that was your intention so I’m leaving the comment otherwise intact.)
Aral,
Ignore the Trolls; clearly the fact that you have a Ruby port submitted by another developer BEFORE YOU’VE EVEN POSTED THAT SUCH A PROJECT HAS BEEN STARTED on the roadmap says that there is some, ever so slight, interest : )
I’m working my way through the Django tutorials at the moment so I’m personally hoping that there will be a handy dandy Python port by the time I’m up to speed (I noticed that, besides the Ruby project, there was also a .Net already in the works mentioned around here somewhere).
As it is I hit this site every week or so just to see what’s cooking…and I’m sure that I’m not the only one!
Keep up the great work.
Thanks, Cynic
Hi Aral,
Some time ago I read a blog post from Ted Patrick (http://www.onflex.org/ted/2007/11/abcs-of-amf.php) in which he explains that there is very little overhead when using AMF with AS3 ByteArrays. He writes: “Fast Serialization/Deserialization - AMF is transformed using native C code in the player so it is blazing fast. The AMF format was designed to serialize and deserialize quickly under low memory and slower CPU conditions. As the AMF data is parsed directly to objects, there is no lag for interpretation or parsing of AMF and creation of objects is done on a single pass.”
Now this made me wonder if SWX AS3 still will perform better in the (de)serialization area in comparison to AMF through ByteArrays on a Flash 9 client. What’s your take on this? Maybe you did some benchmarking on both solutions?
Ted also mentions the added benefit of the standard zlib compression. Is SWX data also zlib compressed?
Hi Benny,
The SWF format is a low-level fundamental building block of the Flash Platform. The Flash Player is very performant in loading and parsing SWF files as that is essentially the core of what it does.
However, I haven’t run any benchmarks on client-side deserialization but I haven’t noticed it to be an issue and my approach is not to worry about optimization issues that are not issues
When I heard this new format, I thought excatly the same thing. Why they tried to invent the wheel, especially, Abode was planned to release AMF as open source.
I was pessimistic about this format.
Performance, file size?
Come on, nowadays hardwares are cheap and fast.
How much swx will gain the benefit unless really remarkable than amf. ( Don’t get me wrong, it’s just my thought. Smart guys will figure out other benefits. )
But if that is for mobile platform, that’s totally different story. It can be even better than AMF, even if AMF existed for Flash lite 1.1, because SWX is bytecode itself. I was realized this can be very useful for Flash lite or limited machine like PSP, Wii, PS3, iPhone(hopefully).
Now I work in Japan, when I developed small app for Flash lite 1.1, it was really painful. So, I took out the most of actionscript from fla file and generate swf file on the fly using SWFScout.
Anyway, my point is in Japan almost every mobile has Flash lite, it has really big market without any proper tools.
But unfortunately, SWX doesn’t support flash 4 which is Flash lite 1.1.
There are 2.0 and 3.0 supporting mobile but 1.1 is still dominant and in terms of performance it’s better.
And the adaptation of new flash lite player is really slow in Japan, I guess because there are not much needs. For user, it’s just the same flash unless they’re developer.
Although I don’t know Ruby ming supports Flash 4.0, if SWX supports Flash lite 1.1, I believe it will bring lots of benefits and possibilities to SWX format.
What do you think?