Thanks for various feedback, all. Based on feedback, I will merge this in at the end of my day.
@Alex, replying to your points: "Maybe XML doesn't have to work in AMF and some subclass like XMLAMF could. That would be more PAYG, and you might then make XMLAMF an IExternalizable instead of adding XML support to the AMF code." re PAYG: I think AMF in general should be considered legacy support. I would be surprised, for example, if lots of people start using AMF remoting in new projects simply because Royale supports it in javascript. I suspect they are more likely to use json or protobuf etc for newer projects. So in my mind, the focus should be on supporting the AMF3 format itself for legacy compatibility, then on performance for that as required. We have BinaryData if people don't want a serialization format. AMF is on top of that. (We actually had this discussion a long time ago :) ). The 'PAYG' approach I intend for XML, Vector, Dictionary which are native types in AMF3, is that there are no actual dependencies created for these types. But it throws errors on reading data if those types are not available to instantiate, so the developer knows that the application will require them added and referenced in the project. The XML write check is not much different to: if (xmlClass && value instanceof xmlClass) writeXML(value) which is the same as the other type checking when writing. xmlClass is defined by a one-off check via reflection (and is only truthy if XML is actually included in the application). Because XML, Vector and Dictionary are native types in AMF, you can't use IExternalizable for any of these and still be compatible with other readers/writers of AMF3 data. IExternalizable is for custom classes, so the approach you mention would not be compatible with something expecting the normal XML content elsewhere - it would also need the corresponding class to exist and be IExternalizable (e.g. on the server). That might mean serverside changes where the goal is to make no serverside changes, which is likely to be a goal in the case of legacy app migrations. So I will proceed to implement as much as I can for these last two types (over time), without any hard dependencies. (Most of the work for this will be outside AMFBinaryData, I think). Then the focus on the future can be on performance improvements if they are required. So far, performance seems to be fine. 2) Check out the SWFOverride metadata. It might do what you want. I'm not a fan of automatically changing imports. I would rather we use conditional compilation. Thanks, that sounds like something I should check out! I won't make changes for now, but I will see if this solves the issue, which is to avoid conditional compilation/complications for regular users (I have no concern about using conditional compilcation in the framework, only about making things simpler/easier for users of the framework). This is only needed because we are not matching the original package name for the native interfaces. On Fri, Mar 8, 2019 at 12:25 AM Harbs <[email protected]> wrote: > I think the changes are OK. > > > On Mar 7, 2019, at 3:41 AM, Greg Dove <[email protected]> wrote: > > > > I meant to do this a few days back, but I continued to make some changes > > and improvements, so here goes: > > The amf_updates branches of compiler and asjs have the following changes > > related to AMFBinaryData: > > > > -The BinaryData base class had a minor shift with the > writeBytes/readBytes > > methods. The original method signature for this method continues to be > > available as writeBinaryData/readBinaryData. The change was made to > conform > > to the original flash interface (and appear the same in javascript). More > > on this in discussion points below. > > > > -AMFBinaryData now extends from BinaryData, and IDataInput, IDataOutput > > both extend from IBinaryDataInput and IBinaryDataOutput (but also the > > native IDataInput and IDataOutput in flash). > > This means that ByteArray code should be more easily ported to royale. > > > > -The main serialization/deserialization support in javascript happens in > a > > separate internal class. It uses Array when writing into its local buffer > > as before and Uint8Array from the main instance when reading. This class > is > > also a subclass of BinaryData, so re-uses the original methods from that > > for certain things that had different implementations before (e.g. UTF > and > > Double) > > > > Additional support has been added for: > > > > -IExtenalizable - decoding and encoding support added for instances of > > classes implementing IExternalizable > > related: updates to mx.collections ArrayList and ArrayCollection. > > org.apache.royale.collections.ArrayList mean that these items now > implement > > IExternalizable > > This has been tested with mx ArrayCollection in the local AMF example > > project (examples/amf/SampleAmfWebApp and > > examples/mxroyale/RemoteObjectAMFTest) > > Also verifed to work with royale ArrayList in Carlos' project (with alias > > remap from ArrayCollection to royale ArrayList) > > > > -Support for 'dynamic' > > dynamic classes are now supported based on updates in reflection data > (some > > limitations based on compile settings, but hopefully unlikely in most > > scenarios). > > > > -IDynamicPropertyWriter support is added. This was something I was > > unfamiliar with in flash, because I had never used it, but I suspect it > > might be more useful in javascript. You can see the original actionscript > > reference here [1]. Basically it allows for control over the > serialization > > of dynamic fields. So you could ignore fields starting with underscore, > for > > example. Or combine fields in a calculation to write a new field that was > > not the same as the original object, etc. This might be useful for plain > > Objects being sent to the server. > > > > -XML encoding/decoding support is added. This has been only tested > briefly > > so far. The AMFBinaryData class does not have a hard dependency on the > XML > > class, so the main project or some library would need to have a > dependency > > on XML for this to work in javascript. An error is thrown in javascript > > when reading XML if the class is not available. > > > > I am working on some minor fixes to XML to get identical results to flash > > with stringification. I am part-way through porting all the trace outputs > > in the XMLTest project to UnitTests to verify that everything else will > > work as before, after my (small) changes. The change I am making will > allow > > for identical byte match tests between flash and javascript for AMF > > encoding of XML (because toXMLString will be identical output) > > > > Discussion notes > > ----------------------- > > > > @Harbs, could you please take a look at the amf_updates branch when you > get > > a chance, I think you were concerned about changes to BinaryData.... > which > > leads me to: > > > > Changes to BinaryData > > > > writeBytes and readBytes using ByteArray in flash and ArrayBuffer in > > javascript > > > > This needs to happen in flash if AMFBinaryData is to implement the same > > IDataOutput/IDataInput as swf. > > That may not be necessary in the end, because the interfaces are a little > > funky, but I personally think it is better to keep it the same as the > > original. I think readBytes and writeBytes in js having ArrayBufffer as > the > > 'native' byte data argument is right, but others may disagree. > ArrayBuffer > > is the native xhr.response and outputs from things like ImageData > (similar > > to flash.display.BitmapData iiuc), so it seems better than Uint8Array to > me > > (Uint8Array is never far away from ArrayBuffer anyway). > > > > I was hoping to have a set of interfaces that could support the AMF > related > > variations (IExternalizable, IDynamicPropertyWriter) which would be > single, > > common imports for both swf and js targets. > > But because these are interfaces expressing methods with arguments that > > typed with other interfaces on swf, you can't get a conforming > > implementation by using an extended interface of the argument type used > in > > the main interface (although, perhaps surprisingly, it does compile ok on > > swf target - it just has a runtime error on instantiating the class). And > > because it is expected in native code we cannot change anything here > > without rewriting everything for swf to work in the same way that we are > > doing in javascript (which does not make sense to me). So we can import a > > common interface for the main implementing class, but not for the > interface > > types it uses in its methods. > > > > Options to avoid double imports of the inner interfaces (the ones used in > > the method arguments defined by the parent interfance) include: > > -Matching the original flash package names in javascript for these > > interfaces. > > flash.utils.* This would be the cleanest way to do things, but I think it > > is contrary to established practice. > > > > -Using some kind of automatic remap of the newer royale-specific > interfaces > > to flash.utils. and flash.net interfaces for swf target in the compiler. > > This would replace imports of the royale classes to imports of the > original > > flash interfaces in the compiler. I am not sure yet how easy this would > be. > > It is probably some sort of automatic import aliasing like Josh > > implemented. If that was possible to implement as metadata on the > original > > class definition that would be the most flexible here (not sure whether > > that is possible, it would be something different to [ExcludeClass]) > > > > Where to from here. > > I am currently working on porting the XML trace-out/console.log tests > > across to UnitTests with assertions. I have made a small change in XML > > class locally that fixes the stringification I think (so now the > > AMFEncoding matches flash), but I will test it against all the tests > that I > > can see with XML to make sure it doesn't affect anything else. > > > > Small messages. > > Carlos tried this, but it wasn't working. Maybe there is a need to change > > something in AMFNetConnection here, I am not sure yet. I will investigate > > more tomorrow and see if I can get this working. > > > > Vector and Dictionary > > These are the remaining Objects not yet implemented (correctly) for amf > > encoding. > > I will take a look at Vector before too long. I know Joshua Granick was > > looking at something here too, but if nothing else took place yet, I will > > be keen to figure out something that could work for > > redlection/serialization. I have personally used Vectors in AMF in the > > past, but not XML or Dictionary (but I think we should be able to do > > something for Dictionary too). > > > > that's enough... this is already too long... > > > > </endOfSaga> > > > > > > > > > > > > 1. > > > https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/ObjectEncoding.html#dynamicPropertyWriter > >
