royale-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Royale - BlazeDS working
Date Thu, 31 May 2018 23:22:24 GMT
Hi Carlos,

I will try to read that in detail later.  However, in a quick read, my takeaway is that the
findings indicated that for up to 2000 data records, JSON was faster than AMF.  And I believe
the test was using the Flash Player, where we now have to consider that for Royale, the AMF
deserialization is running in JavaScript not in the Flash or browser runtime.

Royale does have JSON-to-ValueObject support where the JSON is still parsed in the browser,
but objects are instantiated via JavaScript callbacks.  And as you mention, I think there
are ways to gzip JSON over the wire.  So the comparison environment is totally different for
Royale vs Flex.

So we’ll see if maybe someone can run a test someday and get updated results.

Thanks,
-Alex

From: <carlos.rovira@gmail.com> on behalf of Carlos Rovira <carlosrovira@apache.org>
Reply-To: "users@royale.apache.org" <users@royale.apache.org>
Date: Thursday, May 31, 2018 at 4:07 PM
To: "users@royale.apache.org" <users@royale.apache.org>
Subject: Re: Royale - BlazeDS working

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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.researchgate.net%2Fpublication%2F311750440_Comparative_analysis_of_AMF_JSON_and_XML_technologies_for_data_transfer_between_the_server_and_the_client&data=02%7C01%7Caharui%40adobe.com%7Ca4c6de38ee15443c8f5f08d5c74b5656%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634048747011993&sdata=U2ljIMDjKcYc6Tiqm%2FI063FksxWtlbMmy0%2FGRgE%2Fzsw%3D&reserved=0>

2018-05-31 21:06 GMT+02:00 Alex Harui <aharui@adobe.com<mailto:aharui@adobe.com>>:
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: <carlos.rovira@gmail.com<mailto:carlos.rovira@gmail.com>> on behalf of Carlos
Rovira <carlosrovira@apache.org<mailto:carlosrovira@apache.org>>
Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>" <users@royale.apache.org<mailto:users@royale.apache.org>>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "users@royale.apache.org<mailto:users@royale.apache.org>" <users@royale.apache.org<mailto:users@royale.apache.org>>,
"dev@royale.apache.org<mailto:dev@royale.apache.org>" <dev@royale.apache.org<mailto:dev@royale.apache.org>>
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 <carlosrovira@apache.org<mailto:carlosrovira@apache.org>>:
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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca4c6de38ee15443c8f5f08d5c74b5656%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636634048747032007&sdata=7RXif5%2FxYB0HvseC2hvhehkKflRT8Obi4C7Qr27hPDY%3D&reserved=0>

Mime
View raw message