We have a file format based on AMF. It was used in a Flex application. I would like to migrate the application to Haxe. I was told that the haxe format library had rudimentary AMF reading capabilities and it couldn’t handle custom classes. Is there a better library or was I told something that is incorrect?
The only limitation I saw (looking at the code) is writing an custom class object to amf,
reading an object is fine but will return a
Thank you. It looks like we may have to translate fluorine fx if we want to write amf3.
If we find something that’s appropriately licensed, I’d be glad to see AMF support added to OpenFL ByteArray
We finished our amf3 reader/writer. It leaned on a library licensed with lgpl 2.1. It isnt a direct port but there are parts that were influenced. I believe we would use lgpl 2.1 unless there is a reason against
Works in js, cpp, as3 and probably others. cs has issue extending StringMap (https://github.com/HaxeFoundation/hxcs/issues/34)
Sorry for the delay
LGPL doesn’t work for OpenFL – it “pollutes” code so ALL your code must be released to open-source, if requested. This is an absolute non-starter for anything commercial
That’s been the blocker for us
I thought only GPL licensing was an issue. As far as I know, LGPL doesn’t require you to open source all your code, only GPL does.
Only if you link it against a separately compiled library file, which not all targets can do.
An iOS app can’t do it for instance.
HI @Hoseyhosey ,
Let me ask you one question,
“What is the point of using AMF nowadays?”
The serialization/deserialization would be more expensive in the js side than the minor bytes you can save, also parsing/converting JSON in the js vm is blazing fast.
If you are using Fluorine on the backend, it also supports RPC calls with JSON output.
The backend change is minimal, you only need to add an attribute for every RPC call.
And for the client side Haxe standard HTTP class works like a charm.
PS. We ported a project Flex/FluorineFX/.NET and it’s definitely easier to switch to JSON, and as a bonus point you embrace a common used standard.
The GUI on the front end is currently an SWF. The file format is based on AMF. We are moving away from it but is needed for legacy purposes. We dont really want to put work into the SWF side, if you know what I mean.
How about a small .Net app that uses fluorine to parse AMF, and translates it to JSON?
Then the legacy SWF can use the AMF based file and new developments can be based on “alive” standards