DIGG IT! I am having this inner dilemma about AMF vs XML. For a long time (5 years), I have preferred using AMF over XML. It results in lower over-the-wire bandwidth, faster data serialization/parsing, and you get real class instances in AMF3 when using the full spec (See: Flex Data Services and ColdFusion). Then E4X was added into Flash Player 9 and now I am gradually leaning towards XML for several key use cases:
(New to Flex? Some simple facts first:
1. Flash Player has an XML Parser in it.
2. Flash Player can load XML directly over HTTP/HTTPS.
3. Nothing special is required server side.
4. The XML class implements the E4X (ECMAScript for XML) syntax. Think... readable and writable XPath yet much simpler and tons more fun.
)
Integration with REST
REST API's are blooming everywhere and SOAP seems to be fading rapidly as a client integration format. REST is easy, readable, easy to understand, and best of all it is port 80 friendly.
Queryability
E4X makes client side data easy to query. It is one thing to get an object, it is another to get an object and easily query the data interactively.
Here are a few:
In the loaded XML object named myE4XObj:
Give me elements named 'student' off the root?
myE4XObj.student
Give me 'student' nodes anywhere that have a 'name' attribute?
myE4XObj..student(@name)
Give me 'student' nodes anywhere that a 3.0 or higher grade point average?
myE4XObj..student(@average >= 3)
Now for pure remoting, well that is an AMF thing, for loading models or leaving the result client side queryable, XML with E4X takes the cake. I should note that you can pass XML objects within AMF3 so they remain queryable client side as well, shoot with AMF3 you can pass binary images and SWF files around too.
The problem with AMF is that the secret sauce and recipe are bottled up at Adobe. Although there are many AMF clones out there, they vary wildly in support for the deeper object types in AMF3 binary. They all sort of taste like New Coke or Generic Cola, it tastes similar but something is missing, it is just not the real thing.
What is interesting to me is the fact that AMF is easily 10X faster and lighter than SOAP Web Services for server to server and server to client operations. We have all this server iron out there wasting bandwidth and CPU time parsing XML when they could natively serialize objects with less memory and less bandwidth. AMF3 is a perfect spec for it but we need clients and servers for AMF in many languages first. Currently the AMF format is a transmitter/receiver that can only talk to Flash Player and that needs to change.
I am not sure what 2007 will hold but know that I am lobbying for an open AMF spec in 2007 with server and client implementations for Java/C/CSharp. We need to open up AMF and let it breath. It is really great technology that would enable a wide array of companies leverage efficient data transfer and enjoy native Flash Player data exchange.
2007 is going to be a great year for Flex/Flash/Flash Player/Apollo.
Happy New Year!
Ted :)
While AMF is fast and reduces serialization efforts, I tended to lean toward XML/SOAP because it was open. But... then I saw this performance test:
http://www.jamesward.org/census/
In all the cases where I used XML or AMF the speed difference was insignificant. But, man, those tests were hard to ignore.
I'd like to see AS3 and E4X tests added to that site. But... even if the client can parse xml formats so fast, AMF will still be quicker over the wire.
I would be interested in AMF as an open format--especially because of the points you made about all the different flavors... plus, the fact there are two versions of AMF now (right?).
Not 100% sure this is valid E4X, but I'll wing it ...
amf.open.voter( @name == 'Kevin Hoyt' ).value += 1;
It will be great if AMF becomes an Open Format
Just FYI:
XML is at top level, not flash.xml.XML as you have mentioned
Regards,
Arul
You should really really check JSON out. You can visit the official site: www.json.org
Although it doesn't have good documentation supporting it, it's actually really good.
I've tried it in a few projects and I just love it.
The latest version of PHP already has the JSON extension included, but you can always install it yourself, for php or other languages and you can download the parser to AS.
I'm still trying to figure how to make the best use of it, but if you need some help, say something :)
Open up AMF? Great! And while you're at it can you do the same for RTMP? Thanks.
As for AMF vs E4X, I usually run CF serverside when I want to generate XML dynamically - and who doesn't want it dynamic. While I do that I find it easier to build a few CFCs that return data directly to Flash rather than output XML. But I see where you are coming from... XML is much more flexible and querying a XML tree as if it was a recordset kind of rocks.
Glad to hear your comments on this, Ted. We ended up going with XML because (a) we didn't need or want to afford all the genuinely awesome stuff you get with FDS, and (b) there doesn't seem to be a supported Java/AMF3 package available. Sure, everybody says "OpenAMF" as soon as you say that, but when you start looking you find almost no documentation and almost no project activity. If I was rolling my own app for fun and potential profit, I'd go for it anyway, but we're updating an existing enterprise product and can't bet the company on OpenAMF meeting all our needs as it stands.
Opening up the protocol would be wonderful. I'd even be happy, though, if Adobe could somehow peel off the remoting support for Flex 2/AS3/Java and productize that at a substantial discount from FDS.
Anyway, happy new year :)
The census on James Ward's site corroborates with my own tests on AMF vs. XML speed. Despite XML being much faster than it used to be in Flex 2, parsing it is still slower than AMF. I would say that the difference though is fairly insignificant in a real world test where you probably wouldn't send 5000 rows. While XML can be much more verbose than AMF, if you enable gzip compression on your server, then both will be about the same size. So as far as speed and size concerns go, I would say that they are both pretty much the same.
I also agree that E4X's filtering abilities are neato. On the other hand, in RPC-style, you receive the objects ready to use, so that something like:
data..student
...doesn't make sense, since you would probably have a students array which you would go through. As far as filtering abilities go, although the syntax is different, ArrayCollection.filter does exactly the same thing, and is a bit more flexible.
AMF has a big thing going for it, and you mentioned it, which is class mapping through Object.regiserClass or the RemoteClass metadata tag. Cairngorm and ARP-heads will definitely love this feature, but I guess it's not a big feature for intermediate-level programmers and quick and dirty projects. Another important aspect is ByteArray support, whereas XML doesn't have a proper binary type, but then again, you're not likely to run into that in most projects.
So the question remains: why choose AMF? Well, the thing that bothers me about REST-style XML is that you have to think about the schema that you're going to use. Should I use:
[student id="28" /]
Or:
[student]
[id value="28"]
[/student]
Or:
[student]
[id]28[/id]
[/student]
Or:
[student]
[params]
[param]
[name]id[/name]
[type]integer[/type]
[value]28[/type]
[/param]
[/params]
[/student]
So you have to sit down and think about what kind of schema you're going to use. You have to balance such factors as data size and readability. Then you have to add code to serialize the data, making sure you think about little things like reserved characters, escaping quotes and CDATA blobs. Then you have to define a REST-style interface and document it. What kind of parameters are you going to use? Are you going to gather them through GET or POST? In what format are they going to be sent?
What about data types? XML only has a string type. So you have to add a little bit of code for that.
As a programmer, I don't want to think about these things. If I create a service in amfphp, I can rest assured that the developer only has one URL to remember, and that he can use the service browser to inspect methods and parameters and test it live.
I have no issues with people using XML when they use a ready-made schema that is well documented and has wrappers for it in every other language, like RSS. But when they create their own schemas, I really wonder if they should be focusing on such things instead of features and bug-tracking. Again, I think E4X support in Flex 2 is awesome many levels, and I can definitely see a use for it, but for RPC, AMF makes more sense.
Basically the argument is very similar to the JSON vs. XML one. The conclusion in that case was:
"JSON is a better data exchange format. XML is a better document exchange format. Use the right tool for the right job."
http://www.json.org/xml.html
http://xmlsucks.org/but_you_have_to_use_it_anyway/does-xml-suck.pdf
If you open up the AMF spec, can you push for a Python library! I know you're an old Python lover :)
Hi,
Now that's it's May, can you tell me if we're any closer to Java/AMF3 being a reality w/o FDS?
Thanks!
Michael.
Guyz,
What about the buzz with
RED5 and GDS they are projected as good alternatives for FDS.
Any thoughts on these??
A lot of this alleviated by having mapped objects on both ends. Just as you have between AS3 & CFML.
Data descriptions are best left, in this case, to the functional specs of the application. If well defined, the mapped objects should be no problem.
As far as Binary XML goes... I'm not a fan of that. The term itself is a bit of an oxymoron. XML is, by nature, a text format.
I'm afraid I've found e4x a real pain. Doing anything other than read only simple xml manipulation seems to require black magic solutions that the documentation doesn't show (and things that you think should work don't).
Frankly I'm starting to prefer the old fashioned long hand DOM style manipulation
Well,
I am already using XML/HTTP to exchange data between my flash-client / java-server application.
Should i switch to AMF?
Will i have to use something like Blaze DS or FDS at the backend?
Please advice.
@Josh:
Change to AMF if your application is having performance problems, and you can verify for certain that the performance problems are due to the client and server exchanging huge amounts of XML data over the wire. Alternately, if your application is extremely performance-critical (e.g. real-time game), and milliseconds count, you could change to AMF as well. Otherwise stay with XML.
If you do change, make it so that your application can be switched back and forth between XML mode and AMF mode (don't get rid of the existing functionality).
Maybe I missed it, but I see no mention in these comments of debugging proxy servers like Charles. I would think that a binary format like AMF would be very difficult to debug using Charles or another debugging proxy. With XML, you can immediately see what was sent back and forth. Experienced developers will tell you that 60-80% of the time you spend working on a project is spent debugging it.