royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Royale - BlazeDS working
Date Thu, 31 May 2018 19:06:20 GMT
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> on behalf of Carlos Rovira <carlosrovira@apache.org>
Reply-To: "users@royale.apache.org" <users@royale.apache.org>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "users@royale.apache.org" <users@royale.apache.org>, "dev@royale.apache.org" <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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message