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
> http://about.me/carlosrovira
>
