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 <[email protected]> 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 (<[email protected]>) > 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 >
