Hi Greg, IMO, and waiting for Harbs comments: I think the code is stable to be merged (again, hope Harbs could test and find what changes he should need, but hopefully should be something doable in his codebase, or maybe he found some small tweaks to be done in the branch).
About things still to be done: small messages, improve support for XML and add support for Vector and Dictionary. I think all of this can be done in develop, or as new branches from develop, since are all incremental, but foundation seems to me ok to be merged in the current state, at least we get lots of improvements both in AMF and in Reflection that should go to develop branch as soon as we can. Just my 2....and thanks for this great work :) Carlos El jue., 7 mar. 2019 a las 9:51, Alex Harui (<[email protected]>) escribió: > I read this quickly so may have missed something, but two thoughts came to > mind: > > 1) 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. > > 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. > > HTH, > -Alex > > On 3/7/19, 12: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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.adobe.com%2Fen_US%2FFlashPlatform%2Freference%2Factionscript%2F3%2Fflash%2Fnet%2FObjectEncoding.html%23dynamicPropertyWriter&data=02%7C01%7Caharui%40adobe.com%7C08bdce3231a04acdd59508d6a2d8c250%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875449190432111&sdata=MTZNF1swW8T95N6yD2eURyZIoFjXKjPJ3qK6wp4m290%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
