Re: Royale - BlazeDS working

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:
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!



--
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Alex Harui-2

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: Royale - BlazeDS working

 

 

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:

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

 



 

--

Carlos Rovira

 

Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Harbs
In reply to this post by Carlos Rovira-2
Very impressive! Great work! :-)

Harbs

On May 31, 2018, at 9:51 PM, Carlos Rovira <[hidden email]> wrote:


2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:
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!



--

Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2
In reply to this post by Alex Harui-2
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






2018-05-31 21:06 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: Royale - BlazeDS working

 

 

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:

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

 



 

--

Carlos Rovira

 




--
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Alex Harui-2

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 4:07 PM
To: "[hidden email]" <[hidden email]>
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

 

 

 

 

 

 

2018-05-31 21:06 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: Royale - BlazeDS working

 

 

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:

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

 



 

--

Carlos Rovira

 



 

--

Carlos Rovira

 

Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2
Is good to know JSON is now more capable, I was imagining that. As you say some comparison test will be great. Maybe as we have some time we can do it.
I assume that many people today will use JSON for new apps if the can setup all the interchange with something similar to AMF. If I was to create a new system, fro scratch, I'll be doing that test right now to see differences and choose JSON or AMF. The great benefit of AMF nowadays, without knowing much more about that comparison, is for migration of Flex Apps.

2018-06-01 1:22 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 4:07 PM
To: "[hidden email]" <[hidden email]>


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

 

 

 

 

 

 

2018-05-31 21:06 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: Royale - BlazeDS working

 

 

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:

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

 



 

--

Carlos Rovira

 



 

--

Carlos Rovira

 




--
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2
Reading the document. It uses AMFPHP and Baguetter AMF and the are transferring 76000 records to a Flex Client. I extracted the most interesting:

Adding Baguette AMF plug-in to the basic version of AMF PHP, makes the AMF faster than JSON and XML when transporting larger amounts of data thus providing the Baguette AMF. Baguette AMF with AMFPHP is recommended for enterprise applications which share a large amount of data.

On large number of data, AMF is faster than JSON. InFigure 7., on the basis of measurements in this model, is presented comparison diagram of dependency between the time and the number of data. Figure 7. shows, that up to 2000 data JSON is faster than AMF and above this number, AMF becomes faster. Therefore, it is recommended to use AMF technology above this number of loaded data.

The diagram shows time dependency of the number of data downloaded, with JSON and XML it is much higher compared to the AMF. The Curve which describes the AMF technology, the third line, is of considerably smaller angle, while with JSON, the first line is substantially steeper which means that the time is increasing faster with the number of loaded data. The middle line represents the XML format where we can see that the XML much more depends on JSON when the number of transmitted data increases.

In AMF, the period of data transfer does not depend on the amount of data, because it is binary transmission and is always practically the same.

In JSON and XML the connection period depends on the amount of data, the data is packed in a file in text, and the time of the connection depends on the size of the file. Therefore, the more data, the connection period increases with JSON

The serialization period on the server’s side depends onthe number of objects and if there are more objects to be serialized, then more time is spent which is especially emphasized in JSON and XML because the complexity is greater. Also the more data there is then the file in JSON and XML are heavier and more time is needed to transport data

Conclusions and Future Work
The choice of technology depends on several factors, one of them is the amount of data. By measuring data transfer period in the authoring application it is determined, for a small amount of data, up to 2000, JSON technology is recommended because it is faster, and it is closest to the object structure, orange variant on the graphics. When large amounts of data are used, up to 2000, AMF technology is recommended, blue variant on the graphics.
When it comes to the complexity of the code, AMF technology is recommended, JSON and XML in the end



As you said, our case is different in the deserialization part, but numbers from output from backend I think are always the same.

We should improve as well algorithms now that we have all this working.




2018-06-01 1:45 GMT+02:00 Carlos Rovira <[hidden email]>:
Is good to know JSON is now more capable, I was imagining that. As you say some comparison test will be great. Maybe as we have some time we can do it.
I assume that many people today will use JSON for new apps if the can setup all the interchange with something similar to AMF. If I was to create a new system, fro scratch, I'll be doing that test right now to see differences and choose JSON or AMF. The great benefit of AMF nowadays, without knowing much more about that comparison, is for migration of Flex Apps.

2018-06-01 1:22 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 4:07 PM
To: "[hidden email]" <[hidden email]>


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

 

 

 

 

 

 

2018-05-31 21:06 GMT+02:00 Alex Harui <[hidden email]>:

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: <[hidden email]> on behalf of Carlos Rovira <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Thursday, May 31, 2018 at 11:52 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: Royale - BlazeDS working

 

 

2018-05-31 20:49 GMT+02:00 Carlos Rovira <[hidden email]>:

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

 



 

--

Carlos Rovira

 



 

--

Carlos Rovira

 




--



--
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Justin Mclean
Hi,

You might want to look at this for some performance data as well. It probably could be repurposed and create more current bench marks?

https://www.jamesward.com/2007/04/30/ajax-and-flex-data-loading-benchmarks/

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2
Hi Justin,

thanks for the link. That's the one I was referring ni previous emails. Since is about 10 years old, the old census app seems not to be online. At that time AMF improvements over JSON was huge. I think those days will still be great, but maybe the gap is smaller.

Thanks!

Carlos

2018-06-01 3:43 GMT+02:00 Justin Mclean <[hidden email]>:
Hi,

You might want to look at this for some performance data as well. It probably could be repurposed and create more current bench marks?

https://www.jamesward.com/2007/04/30/ajax-and-flex-data-loading-benchmarks/

Thanks,
Justin



--
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Justin Mclean
Hi,

> thanks for the link. That's the one I was referring ni previous emails. Since is about 10 years old, the old census app seems not to be online. At that time AMF improvements over JSON was huge. I think those days will still be great, but maybe the gap is smaller.

You might want to search the archives (or internet way back machine) I have a vague recollection of James making the code to that app available.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Alex Harui-2
We are not using James Ward's code, so any findings he had would be of questionable use to us.  Even tests against the amf.js we did start from are potentially invalid because we plugged our version into a ClassAlias registry.  It is best if we actually test our code and not somebody else's.

My 2 cents,
-Alex

On 6/1/18, 12:56 AM, "Justin Mclean" <[hidden email]> wrote:

    Hi,
   
    > thanks for the link. That's the one I was referring ni previous emails. Since is about 10 years old, the old census app seems not to be online. At that time AMF improvements over JSON was huge. I think those days will still be great, but maybe the gap is smaller.
   
    You might want to search the archives (or internet way back machine) I have a vague recollection of James making the code to that app available.
   
    Thanks,
    Justin

Reply | Threaded
Open this post in threaded view
|

Re: Royale - BlazeDS working

Carlos Rovira-2
Hi Alex,

Justing doesn't refer to James's implementation of amf.js he did around 2010, but to the old Flex Census app, that was a Flex app that runs a series of tests.
I think it could be of help to make our own. But is clear, as you said, that to get our numbers, we need to create our own from scratch.


2018-06-01 18:46 GMT+02:00 Alex Harui <[hidden email]>:
We are not using James Ward's code, so any findings he had would be of questionable use to us.  Even tests against the amf.js we did start from are potentially invalid because we plugged our version into a ClassAlias registry.  It is best if we actually test our code and not somebody else's.

My 2 cents,
-Alex

On 6/1/18, 12:56 AM, "Justin Mclean" <[hidden email]> wrote:

    Hi,

    > thanks for the link. That's the one I was referring ni previous emails. Since is about 10 years old, the old census app seems not to be online. At that time AMF improvements over JSON was huge. I think those days will still be great, but maybe the gap is smaller.

    You might want to search the archives (or internet way back machine) I have a vague recollection of James making the code to that app available.

    Thanks,
    Justin




--