Hi Alex, I saw some comparison document online [1], let me know what do you think about it.
For me AMF should not only be measured by its benefits on small size and transmission. In that field I think it should win, since json has more overhead, but as I'm not an expert in JSON, I'm sure some serialization will exists. On that way, maybe JSON, could loose the benefits of the easy format to use that make it popular and will probably be more complex to setup and use, so could make AMF be more attractive. Transferring large amount of data I think AMF will be or at least is what I saw in Census App that James Ward did some years ago. Again, nowadays I'm sure things has evolved and maybe JSON could have some additional complement that make it more tiny but at the cost of more complexity. If someone here is more expert, maybe could give some light on latest JSON advantages. (All this without taking into account additional zlib compress and small messages...) But as I said, for me that's not the main benefit. For me AMF wins in ease of development, since I can code a class in AS3 (a DTO, VO, or POJO, each one can call it in some way) and have the mirror class in the backend (Java, .NET, PHP...). So filling an object in AS3 and sending vía AMF put the object ready to use in the backend method. You don't have to make any process to file some object in the other side, or prepare the data to be used, since this is done under the hood. And that's is very comfortable. Having the same types (the counterpart in the other side) makes all very easy and that's productivity. Maybe JSON can do today something similar...I'm sure something should be out there. Finally for us means to have other tool in our arsenal, a great tool that many people out there doesn't know or thinks on it as it's still some proprietary Adobe technology. And more important, means that many people with Flex apps have now a more easy way to migrate, since they don't need to touch a line of code in their backends. I think that's a huge win. Since instead of planning a full refactor of an entire system (front and back) people can concentrate in front with Royale. Plant side by side with his current Flex App and make it grow from there, and some day turn off flex and turn on Royale :) That's at least my plan with our system :) Thanks! Carlos [1] https://www.researchgate.net/publication/311750440_Comparative_analysis_of_AMF_JSON_and_XML_technologies_for_data_transfer_between_the_server_and_the_client 2018-05-31 21:06 GMT+02:00 Alex Harui <[email protected]>: > Hi Carlos, > > > > That’s great news! > > > > One thing I would like to see someday (not necessarily from you, maybe > some other user) is a comparison of JSON vs AMF. For some real-world > server response, what would be the number of bytes transferred and what > would be the CPU processing time in the browser to convert the data into > “Value Objects”. > > > > Thanks, > > -Alex > > > > *From: *<[email protected]> on behalf of Carlos Rovira < > [email protected]> > *Reply-To: *"[email protected]" <[email protected]> > *Date: *Thursday, May 31, 2018 at 11:52 AM > *To: *"[email protected]" <[email protected]>, " > [email protected]" <[email protected]> > *Subject: *Re: Royale - BlazeDS working > > > > Forgot to share the info in Github page :) > > > > https://github.com/apache/royale-asjs/wiki/Apache- > Royale-communication-with-AMF-and-RemoteObject > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FApache-Royale-communication-with-AMF-and-RemoteObject&data=02%7C01%7Caharui%40adobe.com%7C35acbd7109734fdb4e4d08d5c727a05e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636633895374721172&sdata=RkbeMMs22sIHVZ0meRLVzGC0VsRUOA1ykl5llHXrvfE%3D&reserved=0> > > > > 2018-05-31 20:49 GMT+02:00 Carlos Rovira <[email protected]>: > > Hi, > > > > I get Royale working with BlazeDS. People using BlazeDS should be able to > finally start developing with Royale now! :) > > > > Right now I'm test it with both the SampleAmfWebApp (in our repo) and with > my own backend (real flex/java app), and seems to work in both. > > > > Things to have into account: While "clientId" is now working (we send the > required PING command, get the DSId and store it for later communication), > we need to use it with small messages turned off (blazeds turn it on by > default). > > > > This is the configuration per channel: > > > > <channel-definition ...> > > <properties> > > <serialization> > > <enable-small-messages>false</enable-small-messages> > > </serialization> > > > > I think small messages are only something that will make our > implementation shine, but really is not required. I think that will improve > a bit over the normal message size. If you use as well the > CompressedRemoteObject, that will be a killer communication! :) > > > > About small messages, I'm trying to get it work, I uploaded the work > currently done, but still needs more to get it fully working. > > > > As well I uploaded a SimpleRemoteObject that is a simpler version that > should work with AMF backends that require less things like AMFPHP. As I > don't use AMFPHP since many years I can say too much about it, but hope > others will use and report if something more is needed (The same for other > AMF implementations in other technologies). > > > > Thanks! > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C35acbd7109734fdb4e4d08d5c727a05e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636633895374721172&sdata=%2F%2FeMiAc533chEQ5po1rV%2B9tMGMLEja4Yty%2BMg0t1j8U%3D&reserved=0> > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C35acbd7109734fdb4e4d08d5c727a05e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636633895374877422&sdata=DJRVjcGCk26lBJoBify1%2B9O0TDqRZEGdNu4ARqglWLA%3D&reserved=0> > > > -- Carlos Rovira http://about.me/carlosrovira
