This is a major US holiday week, so not a good week for trying to get internal documents released. So looking at the code in AVMPlus is probably as good as it will get.
I could be wrong, but I would think IExternalizable would not affect the byte stream very much at all. I would think its only impact would be to pass the bytes to the implementing class. The goal, AIUI, isn't to encode an ArrayCollection into the bytes, it is to take a subset of the AC properties and put them in the stream so that the deserialization code in BlazeDS and AMFPHP can decode it into whatever class represents AC on the server. So not only do you have AVMPlus code to reference, I think there may be code in BlazeDS. I would think the basic AMF deserialization logic currently is: ReadAlias (of the first class in the stream) GetClassFromAlias New Class Read property list of class. readAlias (the type of the first property in the property list GetClassFromAlias New Class (to get an object that is the value of that first property) Recursively deserialize that object Set the first property to that object Loop. IMO, IExternalizable is only supposed to break out of this pattern and call the implementation to recursively deserialize the object. I think the code just needs to add a check after getClassFromAlias that determines if the instance is IExternalizable and then skips getting the property list and just calls readExternal. Of course, I could be wrong... -Alex On 11/20/18, 3:48 AM, "Frost, Andrew" <[email protected]> wrote: Hi guys I'm not 100% sure whether this will help, but if I'm right in thinking that what you're trying to do is to mimic the Flash object serialisation, then I think that this information is actually in the public domain already.. Carlos, you wrote: "ArrayCollection uses IExternalizable and that part is our main problem since we don’t have references, just simple docs but no real implementation, guides or notes about it." The IExternalizable.as implementation is part of avmplus: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Favmplus%2Fblob%2Fmaster%2Fcore%2FIExternalizable.as&data=02%7C01%7Caharui%40adobe.com%7C7f8e0db9f16949ac3e7608d64ede0f07%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636783112976645298&sdata=wKxHyqX9baCjWeKfLAndXL%2FzeP%2FqKarCRAWseiSXbE8%3D&reserved=0 ArrayCollection is of course part of Flex: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fflex-sdk%2Fblob%2Fmaster%2Fframeworks%2Fprojects%2Fframework%2Fsrc%2Fmx%2Fcollections%2FArrayCollection.as&data=02%7C01%7Caharui%40adobe.com%7C7f8e0db9f16949ac3e7608d64ede0f07%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636783112976655307&sdata=nEL5UEBaLGPzsyl%2BiYdVjGoOZjI9h0wUG2DP9k78IMo%3D&reserved=0 and you can then follow through what's happening. And, having just done that, I'm guessing you're looking at how "readObject" works. Presumably you're serialising into a ByteArray, which means ultimately you'll end up in the heart of the avmplus code: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Favmplus%2Fblob%2Fmaster%2Fcore%2FToplevel.cpp%23L1504&data=02%7C01%7Caharui%40adobe.com%7C7f8e0db9f16949ac3e7608d64ede0f07%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636783112976655307&sdata=%2FREpZDXXbbb9dUY7UNYCCezDIgKOec2ct4AdCHZ6z1o%3D&reserved=0 and https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Favmplus%2Fblob%2Fmaster%2Fcore%2FAvmSerializer.cpp&data=02%7C01%7Caharui%40adobe.com%7C7f8e0db9f16949ac3e7608d64ede0f07%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636783112976655307&sdata=Ld20xC%2Fb4Qtmiy8mzrG3QMltvPU37wxYdclE6nsueQM%3D&reserved=0 which is quite complex...! Not sure if those help at all but it looks to me like it should be possible to have some JavaScript code to do all this. If this is the sort of area that you're looking at then let me know, I've got extensive experience with the avmplus code and have builds of it that I can tweak/play with to debug what happens in various scenarios! but I don't have any experience with using RemoteObject hence this may all be completely irrelevant.. thanks Andrew -----Original Message----- From: Greg Dove [mailto:[email protected]] Sent: 20 November 2018 09:47 To: [email protected] Subject: [EXTERNAL] Re: Problems sending MX ArrayCollections with MX RemoteObject Hi Alex, To follow on from what Carlos explained... your initial implementation with AMFBinaryData was working quite well for smaller object graphs. And I was able to make some changes to get it to special-case ArrayCollection for now on the reading side (it's not a proper implementation, but it was to get things working for now). What I am missing is some good implementation notes ('conforming readers and writers must do this'). For example, I'm not sure what the object table (rememberObject/traitsByReference) rules are for Externalizables, and it's really hard to 'discover' through comparisons with things like ByteArray or BlazeDS responses partly because the undefined output order of the fields in a large graph which makes direct comparison of byte sequences from the 2 sources not so easy. In the end I will be happy to keep working on getting AMFBinaryData fully featured in my own time to help with the general MX effort, but Carlos needs certain things working for his project, which are our current priorities. I do have some improvements that I can get in for AMFBinaryData in the next few days (I'm still refining things): I have some code that avoids inappropriate field data for serialization: only accessors with readwrite access (not getter only or setter only) no static accessors or variables excludes any field with 'Transient' metadata But I'm still actively trying to figure out how to get the AC writing correctly in a complex graph, and I really need to understand what the rules are supposed to be. In terms of 'Externalizable' AC seems quite simple, so I thought it would be easy... but I think I am messing up the object reference table when I do this... I was hoping there might be something documented for implentation notes that is 'public' but 'not well publicized' that you might be aware of, perhaps through some of your internal connections. if we can get this fully fledged as quickly as possible, even if it just focused on AC for now on the 'Externalizable' side then that will help Alina and others as well, I think. I've had my head in this for a bit now, so if I have the info, I will find the time. Hopefully you can provide some insight! -Greg On Tue, Nov 20, 2018 at 10:19 PM Carlos Rovira <[email protected]> wrote: > Hi Alex, > > Greg and I are working this days in sending MX ArrayCollection with MX > RemoteObject to BlazeDS. We found that part is not working. > This is huge problem since without solving this we can't progress in > our migration, so hope you could take care of this issue and help us > to find the solution. > > The main problem is that we don't have or find a good reference of the > way it should be implemented and the format makes it difficult to discover. > ArrayCollection uses IExternalizable and that part is our main problem > since we don’t have references, just simple docs but no real > implementation, guides or notes about it. > > Our better bet is that you could get some help at Adobe internally > since I don't think this info is in internet (at least we search > heavily to try to find). > > I think with out this problem fixed no application using MX > RemoteObject for communication could be migrated from Flex to Royale, > since as soon they want to send and complex graph that uses MX ArrayCollection it will fail. > > Greg can comment more about this problem since he was working hard on > the issue this days. > > Thanks in advance for your help > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclicktime.symantec.com%2Fa%2F1%2FfECozPwEKwcw-Ikf3a3HC4wIeBurGWwaEzA&data=02%7C01%7Caharui%40adobe.com%7C7f8e0db9f16949ac3e7608d64ede0f07%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636783112976655307&sdata=aPa7RjRka%2BB9jCAr1WR5KRlvGKDsCkLK7%2FabYkvxrMg%3D&reserved=0 > E2QRfLRk=?d=ezg34mnblPal5Fyvz8kFGVPZYWSwgwTIshTP4R6ZZBwOU_9DnOO0vulBQk > WMjrartx1QiEcmaQF0W-s21xYUmmwd8VZI2paWYczV2yv9_RGOX7HvcYTbT5-boGyLZsXs > i81oDbXjP_kE8HOHv-CO0RmzekCJ4IXZ1dfI4iczGVVKJlFs3Z9QfZKPIsqL8bfsOPw83b > 72ng2yLuRO4g252wF9TWPtu2CAYr-VXOzqqiXrKi2Zrk9wM3FFEc9hUJ9dpb5b4bflw_r8 > nj8z30JVYIfUlmah923Rr-8mDPJO0JvmMDiSEWJojxBQAi_wWktydSWyDvGSDJidxjtFsq > UpjRFuCNjuBFxim5GH2bZCj-0Gra3yfagBCVNYiT95Zq5loJN_-kHI8W8-jEOaVK-3Hgd4 > iAgxK7oB4xr5-PopRVTJDHsb3OeOqtd9_rjFDbCq0EtWEowCy2xcWbcBzo0IiQhRTv3Mrs > x48H3qjmo%3D&u=http%3A%2F%2Fabout.me%2Fcarlosrovira >
