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
