You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Hugo Ferreira <hf...@gmail.com> on 2020/07/05 13:28:52 UTC
Royale SimpleRemoteObject compatible with my .NET AMF Library
Hello,
I have my own .NET AMF Library implementation, compatible with both .NET,
Mono, Xamarin and .NET Core thru .NET Standard.
Testing SimpleRemoteObject (after solving the CORS issue on debug mode), I
faced an issue and I just fixed it and put my .NET AMF library compatible
with both Royale SimpleRemoteObject and Flex RemoteObject and it's working
thine (for the first Hello World test)!
The point is, with Flex RemoteObject, the ping operation uses the constant
5 (client ping operation) but with Royale SimpleRemoteObject this constant
changed to 13.
Any particular reason for this?
Is it to identify the backend that the caller is Royale instead of Flex?
Can I confident add this value 13 to my enumeration and commit my library
that will not change in the near future (now compatible with Royale)?
Regards,
Hugo.
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Hugo Ferreira <hf...@gmail.com>.
Hi,
Thank you for your input.
I will continue my tests and make a decision soon.
Carlos Rovira <ca...@apache.org> escreveu no dia segunda, 6/07/2020
à(s) 17:09:
> Hi,
>
> don't understand me wrong. Network implementations should be something to
> continue evolving over time to get something more "royale" than flex
> implementation (bead implementation, less weight,...). But right now RPC is
> the part of MXRoyale that you still require to use AMF in the right way.
>
>
> El lun., 6 jul. 2020 a las 17:47, Hugo Ferreira (<hf...@gmail.com>)
> escribió:
>
> > Hi Carlos,
> >
> > Ho, I thought that SimpleRemoteObject was ready for production and it's
> > missing a few properties (compared with mx:RemoteObject) just because as
> > you said, it's a new start.
> >
> > Thank you.
> >
> >
> > Carlos Rovira <ca...@apache.org> escreveu no dia segunda,
> 6/07/2020
> > à(s) 15:59:
> >
> > > Hi Hugo,
> > >
> > > I don't remember about the codes, but I I found lots of problems. I
> > > remember I need to change to mx:RemoteObject to get it working in our
> > first
> > > migration.
> > > I think SimpleRemoteObject is a good start, but needs more work to be a
> > > valid replacement. If you want to contribute to it, that's very good.
> > > Thanks
> > >
> > > El lun., 6 jul. 2020 a las 10:38, Hugo Ferreira (<
> hferreira.80@gmail.com
> > >)
> > > escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > But do you know if the ping contant 13 it's the normal way of
> > > > SimpleRemoting or it's a bug that can change in a near future ?
> > > >
> > > > Carlos Rovira <ca...@apache.org> escreveu no dia segunda,
> > > 6/07/2020
> > > > à(s) 08:37:
> > > >
> > > > > Hi Hugo,
> > > > >
> > > > > as I just responded in other email, please don't use Network AMF
> > > > > implementations, you must use MXRoyale implementations since you're
> > > > > migrating
> > > > > from an existing AMF backend. We have clients using .NET and AMF
> and
> > > all
> > > > is
> > > > > working fine. So you'll get the same as you have now in Flex.
> > > > > If you find some bug please create an issue, but implementation
> seems
> > > all
> > > > > ok.
> > > > >
> > > > > Remember to add:
> > > > >
> > > > >
> > > >
> > >
> >
> -compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
> > > > > to avoid CSS issues. We still need to separate RPC code from
> MXRoyale
> > > > some
> > > > > day to a MXRPC lib to avoid this problem.
> > > > > Any help on this is appreciated.
> > > > >
> > > > > Thanks
> > > > >
> > > > > El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<
> > > hferreira.80@gmail.com
> > > > >)
> > > > > escribió:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I have my own .NET AMF Library implementation, compatible with
> both
> > > > .NET,
> > > > > > Mono, Xamarin and .NET Core thru .NET Standard.
> > > > > >
> > > > > > Testing SimpleRemoteObject (after solving the CORS issue on debug
> > > > mode),
> > > > > I
> > > > > > faced an issue and I just fixed it and put my .NET AMF library
> > > > compatible
> > > > > > with both Royale SimpleRemoteObject and Flex RemoteObject and
> it's
> > > > > working
> > > > > > thine (for the first Hello World test)!
> > > > > >
> > > > > > The point is, with Flex RemoteObject, the ping operation uses the
> > > > > constant
> > > > > > 5 (client ping operation) but with Royale SimpleRemoteObject this
> > > > > constant
> > > > > > changed to 13.
> > > > > > Any particular reason for this?
> > > > > > Is it to identify the backend that the caller is Royale instead
> of
> > > > Flex?
> > > > > > Can I confident add this value 13 to my enumeration and commit my
> > > > library
> > > > > > that will not change in the near future (now compatible with
> > Royale)?
> > > > > >
> > > > > > Regards,
> > > > > > Hugo.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > > http://about.me/carlosrovira
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
don't understand me wrong. Network implementations should be something to
continue evolving over time to get something more "royale" than flex
implementation (bead implementation, less weight,...). But right now RPC is
the part of MXRoyale that you still require to use AMF in the right way.
El lun., 6 jul. 2020 a las 17:47, Hugo Ferreira (<hf...@gmail.com>)
escribió:
> Hi Carlos,
>
> Ho, I thought that SimpleRemoteObject was ready for production and it's
> missing a few properties (compared with mx:RemoteObject) just because as
> you said, it's a new start.
>
> Thank you.
>
>
> Carlos Rovira <ca...@apache.org> escreveu no dia segunda, 6/07/2020
> à(s) 15:59:
>
> > Hi Hugo,
> >
> > I don't remember about the codes, but I I found lots of problems. I
> > remember I need to change to mx:RemoteObject to get it working in our
> first
> > migration.
> > I think SimpleRemoteObject is a good start, but needs more work to be a
> > valid replacement. If you want to contribute to it, that's very good.
> > Thanks
> >
> > El lun., 6 jul. 2020 a las 10:38, Hugo Ferreira (<hferreira.80@gmail.com
> >)
> > escribió:
> >
> > > Hi Carlos,
> > >
> > > But do you know if the ping contant 13 it's the normal way of
> > > SimpleRemoting or it's a bug that can change in a near future ?
> > >
> > > Carlos Rovira <ca...@apache.org> escreveu no dia segunda,
> > 6/07/2020
> > > à(s) 08:37:
> > >
> > > > Hi Hugo,
> > > >
> > > > as I just responded in other email, please don't use Network AMF
> > > > implementations, you must use MXRoyale implementations since you're
> > > > migrating
> > > > from an existing AMF backend. We have clients using .NET and AMF and
> > all
> > > is
> > > > working fine. So you'll get the same as you have now in Flex.
> > > > If you find some bug please create an issue, but implementation seems
> > all
> > > > ok.
> > > >
> > > > Remember to add:
> > > >
> > > >
> > >
> >
> -compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
> > > > to avoid CSS issues. We still need to separate RPC code from MXRoyale
> > > some
> > > > day to a MXRPC lib to avoid this problem.
> > > > Any help on this is appreciated.
> > > >
> > > > Thanks
> > > >
> > > > El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<
> > hferreira.80@gmail.com
> > > >)
> > > > escribió:
> > > >
> > > > > Hello,
> > > > >
> > > > > I have my own .NET AMF Library implementation, compatible with both
> > > .NET,
> > > > > Mono, Xamarin and .NET Core thru .NET Standard.
> > > > >
> > > > > Testing SimpleRemoteObject (after solving the CORS issue on debug
> > > mode),
> > > > I
> > > > > faced an issue and I just fixed it and put my .NET AMF library
> > > compatible
> > > > > with both Royale SimpleRemoteObject and Flex RemoteObject and it's
> > > > working
> > > > > thine (for the first Hello World test)!
> > > > >
> > > > > The point is, with Flex RemoteObject, the ping operation uses the
> > > > constant
> > > > > 5 (client ping operation) but with Royale SimpleRemoteObject this
> > > > constant
> > > > > changed to 13.
> > > > > Any particular reason for this?
> > > > > Is it to identify the backend that the caller is Royale instead of
> > > Flex?
> > > > > Can I confident add this value 13 to my enumeration and commit my
> > > library
> > > > > that will not change in the near future (now compatible with
> Royale)?
> > > > >
> > > > > Regards,
> > > > > Hugo.
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Hugo Ferreira <hf...@gmail.com>.
Hi Carlos,
Ho, I thought that SimpleRemoteObject was ready for production and it's
missing a few properties (compared with mx:RemoteObject) just because as
you said, it's a new start.
Thank you.
Carlos Rovira <ca...@apache.org> escreveu no dia segunda, 6/07/2020
à(s) 15:59:
> Hi Hugo,
>
> I don't remember about the codes, but I I found lots of problems. I
> remember I need to change to mx:RemoteObject to get it working in our first
> migration.
> I think SimpleRemoteObject is a good start, but needs more work to be a
> valid replacement. If you want to contribute to it, that's very good.
> Thanks
>
> El lun., 6 jul. 2020 a las 10:38, Hugo Ferreira (<hf...@gmail.com>)
> escribió:
>
> > Hi Carlos,
> >
> > But do you know if the ping contant 13 it's the normal way of
> > SimpleRemoting or it's a bug that can change in a near future ?
> >
> > Carlos Rovira <ca...@apache.org> escreveu no dia segunda,
> 6/07/2020
> > à(s) 08:37:
> >
> > > Hi Hugo,
> > >
> > > as I just responded in other email, please don't use Network AMF
> > > implementations, you must use MXRoyale implementations since you're
> > > migrating
> > > from an existing AMF backend. We have clients using .NET and AMF and
> all
> > is
> > > working fine. So you'll get the same as you have now in Flex.
> > > If you find some bug please create an issue, but implementation seems
> all
> > > ok.
> > >
> > > Remember to add:
> > >
> > >
> >
> -compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
> > > to avoid CSS issues. We still need to separate RPC code from MXRoyale
> > some
> > > day to a MXRPC lib to avoid this problem.
> > > Any help on this is appreciated.
> > >
> > > Thanks
> > >
> > > El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<
> hferreira.80@gmail.com
> > >)
> > > escribió:
> > >
> > > > Hello,
> > > >
> > > > I have my own .NET AMF Library implementation, compatible with both
> > .NET,
> > > > Mono, Xamarin and .NET Core thru .NET Standard.
> > > >
> > > > Testing SimpleRemoteObject (after solving the CORS issue on debug
> > mode),
> > > I
> > > > faced an issue and I just fixed it and put my .NET AMF library
> > compatible
> > > > with both Royale SimpleRemoteObject and Flex RemoteObject and it's
> > > working
> > > > thine (for the first Hello World test)!
> > > >
> > > > The point is, with Flex RemoteObject, the ping operation uses the
> > > constant
> > > > 5 (client ping operation) but with Royale SimpleRemoteObject this
> > > constant
> > > > changed to 13.
> > > > Any particular reason for this?
> > > > Is it to identify the backend that the caller is Royale instead of
> > Flex?
> > > > Can I confident add this value 13 to my enumeration and commit my
> > library
> > > > that will not change in the near future (now compatible with Royale)?
> > > >
> > > > Regards,
> > > > Hugo.
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Carlos Rovira <ca...@apache.org>.
Hi Hugo,
I don't remember about the codes, but I I found lots of problems. I
remember I need to change to mx:RemoteObject to get it working in our first
migration.
I think SimpleRemoteObject is a good start, but needs more work to be a
valid replacement. If you want to contribute to it, that's very good.
Thanks
El lun., 6 jul. 2020 a las 10:38, Hugo Ferreira (<hf...@gmail.com>)
escribió:
> Hi Carlos,
>
> But do you know if the ping contant 13 it's the normal way of
> SimpleRemoting or it's a bug that can change in a near future ?
>
> Carlos Rovira <ca...@apache.org> escreveu no dia segunda, 6/07/2020
> à(s) 08:37:
>
> > Hi Hugo,
> >
> > as I just responded in other email, please don't use Network AMF
> > implementations, you must use MXRoyale implementations since you're
> > migrating
> > from an existing AMF backend. We have clients using .NET and AMF and all
> is
> > working fine. So you'll get the same as you have now in Flex.
> > If you find some bug please create an issue, but implementation seems all
> > ok.
> >
> > Remember to add:
> >
> >
> -compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
> > to avoid CSS issues. We still need to separate RPC code from MXRoyale
> some
> > day to a MXRPC lib to avoid this problem.
> > Any help on this is appreciated.
> >
> > Thanks
> >
> > El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<hferreira.80@gmail.com
> >)
> > escribió:
> >
> > > Hello,
> > >
> > > I have my own .NET AMF Library implementation, compatible with both
> .NET,
> > > Mono, Xamarin and .NET Core thru .NET Standard.
> > >
> > > Testing SimpleRemoteObject (after solving the CORS issue on debug
> mode),
> > I
> > > faced an issue and I just fixed it and put my .NET AMF library
> compatible
> > > with both Royale SimpleRemoteObject and Flex RemoteObject and it's
> > working
> > > thine (for the first Hello World test)!
> > >
> > > The point is, with Flex RemoteObject, the ping operation uses the
> > constant
> > > 5 (client ping operation) but with Royale SimpleRemoteObject this
> > constant
> > > changed to 13.
> > > Any particular reason for this?
> > > Is it to identify the backend that the caller is Royale instead of
> Flex?
> > > Can I confident add this value 13 to my enumeration and commit my
> library
> > > that will not change in the near future (now compatible with Royale)?
> > >
> > > Regards,
> > > Hugo.
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Hugo Ferreira <hf...@gmail.com>.
Hi Carlos,
But do you know if the ping contant 13 it's the normal way of
SimpleRemoting or it's a bug that can change in a near future ?
Carlos Rovira <ca...@apache.org> escreveu no dia segunda, 6/07/2020
à(s) 08:37:
> Hi Hugo,
>
> as I just responded in other email, please don't use Network AMF
> implementations, you must use MXRoyale implementations since you're
> migrating
> from an existing AMF backend. We have clients using .NET and AMF and all is
> working fine. So you'll get the same as you have now in Flex.
> If you find some bug please create an issue, but implementation seems all
> ok.
>
> Remember to add:
>
> -compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
> to avoid CSS issues. We still need to separate RPC code from MXRoyale some
> day to a MXRPC lib to avoid this problem.
> Any help on this is appreciated.
>
> Thanks
>
> El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<hf...@gmail.com>)
> escribió:
>
> > Hello,
> >
> > I have my own .NET AMF Library implementation, compatible with both .NET,
> > Mono, Xamarin and .NET Core thru .NET Standard.
> >
> > Testing SimpleRemoteObject (after solving the CORS issue on debug mode),
> I
> > faced an issue and I just fixed it and put my .NET AMF library compatible
> > with both Royale SimpleRemoteObject and Flex RemoteObject and it's
> working
> > thine (for the first Hello World test)!
> >
> > The point is, with Flex RemoteObject, the ping operation uses the
> constant
> > 5 (client ping operation) but with Royale SimpleRemoteObject this
> constant
> > changed to 13.
> > Any particular reason for this?
> > Is it to identify the backend that the caller is Royale instead of Flex?
> > Can I confident add this value 13 to my enumeration and commit my library
> > that will not change in the near future (now compatible with Royale)?
> >
> > Regards,
> > Hugo.
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Royale SimpleRemoteObject compatible with my .NET AMF Library
Posted by Carlos Rovira <ca...@apache.org>.
Hi Hugo,
as I just responded in other email, please don't use Network AMF
implementations, you must use MXRoyale implementations since you're
migrating
from an existing AMF backend. We have clients using .NET and AMF and all is
working fine. So you'll get the same as you have now in Flex.
If you find some bug please create an issue, but implementation seems all
ok.
Remember to add:
-compiler.exclude-defaults-css-files=MXRoyale-${royale.framework.version}-js.swc:defaults.css;
to avoid CSS issues. We still need to separate RPC code from MXRoyale some
day to a MXRPC lib to avoid this problem.
Any help on this is appreciated.
Thanks
El dom., 5 jul. 2020 a las 15:29, Hugo Ferreira (<hf...@gmail.com>)
escribió:
> Hello,
>
> I have my own .NET AMF Library implementation, compatible with both .NET,
> Mono, Xamarin and .NET Core thru .NET Standard.
>
> Testing SimpleRemoteObject (after solving the CORS issue on debug mode), I
> faced an issue and I just fixed it and put my .NET AMF library compatible
> with both Royale SimpleRemoteObject and Flex RemoteObject and it's working
> thine (for the first Hello World test)!
>
> The point is, with Flex RemoteObject, the ping operation uses the constant
> 5 (client ping operation) but with Royale SimpleRemoteObject this constant
> changed to 13.
> Any particular reason for this?
> Is it to identify the backend that the caller is Royale instead of Flex?
> Can I confident add this value 13 to my enumeration and commit my library
> that will not change in the near future (now compatible with Royale)?
>
> Regards,
> Hugo.
>
--
Carlos Rovira
http://about.me/carlosrovira