You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2019/03/07 08:41:40 UTC
AMF updates
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
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
Alex, I addressed the dependency order issue, which should solve things for
that part.
I will also address the ArrayList (remove IExternalizable) in the near
future - before mid-month, but it has implications in Carlos' current
project, so I will hold off for this week. I'll revisit the dependency
order and remove unnecessary dependency on Network from Collections as well.
On Sun, Mar 31, 2019 at 7:49 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Feel free to make subclass of ArrayList in Express that has
> IExternalizable code for enterprise grade development. Or create a new SWC
> for enterprise grade stuff. Royale's Basic should serve folks trying to
> make small apps that are not necessarily enterprise grade. That's why we
> are trying to promote PAYG throughout the framework. I expect in the end
> that other SWCs besides Basic will be more popular (Jewel, Express or some
> new Enterprise SWC), but we want Basic to be around for the folks who are
> trying to shrink something down or speed something up.
>
> Thanks,
> -Alex
>
> On 3/30/19, 11:32 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> I see it now, I had not noticed that before.... it is not present in
> the
> maven build so maybe I did not correctly set up the dependency order
> for
> ant, sorry. I will take a look at it tomorrow my time.
>
> In terms of ArrayList and IExternalizable, is it not reasonable to
> assume
> that serialization will be useful in the general case, for enterprise
> grade
> development?
> IExternalizable is useful for amf now, but it could be harnessed, I
> believe, for other types of serialization, like custom json which
> includes
> type data etc (it won't be as compact as amf, but maybe it could be
> faster
> to encode/decode and easy to build serverside support for it).
>
>
>
>
> On Sun, Mar 31, 2019 at 6:47 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Is anybody else seeing this warning when building Basic .swc?
> >
> > Warning: The definition org.apache.royale.net.utils.IExternalizable
> > depended on by org.apache.royale.collections.ArrayList in the SWC
> >
> /Users/aharui/git/royale/ant/royale-asjs/frameworks/libs/Collections.swc
> > could not be found
> >
> > IMO, ArrayList should not implement IExternalizable for PAYG reasons.
> > Some subclass should. And that would likely resolve the build order
> issue.
> >
> > Thanks,
> > -Alex
> >
> > On 3/7/19, 5:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > 'I thought that even native AS types (int, number, string)
> essentially
> > had
> > a class alias in the AMF data and thus XML and Dictionary would
> too.'
> >
> > I expect they probably have actual traits information in the avm
> > implementation for more general purposes and for consistency. But
> > these are
> > treated specially and are not amf encoded with traits info. This
> means
> > that
> > registerClassAlias has no effect on the encoding, at least for
> the
> > standard
> > types - I did check this in flash with a String test, but did
> not go
> > through all of them. The established
> serialization/deserialization code
> > itself provides the clues for this.
> >
> > I assume this is done because they are always encoded in what is
> > (presumably) the most compact form. As a quick example, a
> Boolean is
> > encoded with one byte that serves both as its type and its
> value. Any
> > implementation using traits or aliasing would be much less
> compact. So
> > each
> > of these has their own type codes in AMF, and are treated
> differently
> > to
> > other more general objects (including class instances) which *do*
> > include
> > traits information (or reference it if there has been previous
> access
> > to
> > that specific traits) in the serialized format and they do
> require a
> > registered alias to decode back to the class instance instead of
> > anonymous
> > object.
> >
> > iirc from experience, there was a need to have the 'generic'
> type of a
> > vector.<Class> aliased, and maybe the Vector<Class> variation
> aliased
> > also,
> > because I think these are another case... but that will be for
> another
> > time
> > and I will check it then. Vector<int>, <uint> and <Number> are
> also
> > special-cased, and I also expect they will ignore aliasing,
> because it
> > would only add unnecessary weight to the encoded content. But I
> will
> > look
> > in the tamarin code when I get to that (we need a concrete Vector
> > implementation first, or at least some way to tag the Array
> instances
> > that
> > represent Vectors for runtime checks).
> >
> >
> >
> >
> >
> > On Fri, Mar 8, 2019 at 1:05 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > Well, maybe you can answer this one question:
> > >
> > > I thought that even native AS types (int, number, string)
> > essentially had
> > > a class alias in the AMF data and thus XML and Dictionary would
> > too. And
> > > then in theory, anyone could change the class alias map to map
> the
> > alias
> > > for XML to something else. How are native types represented
> in AMF
> > data?
> > > How does the decode know it is a String, int, Number or XML?
> > >
> > > Thanks,
> > > -Alex
> > >
> > > On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
> > >
> > > Correction: That doesn't mean I *have* thought ...etc
> > >
> > > On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <
> greg.dove@gmail.com>
> > wrote:
> > >
> > > > I'm not concerned about download size of AMF code unless
> > support for
> > > > lesser-used classes are significant.
> > > >
> > > > OK, so I think I have that. XML is very PAYG. It only
> works for
> > > writing if
> > > > you use XML already elsewhere in your project (if you
> did not
> > do
> > > that, then
> > > > you could never write an XML instance in any case!). And
> it
> > throws
> > > errors
> > > > if XML is needed for reading, but not included in your
> > project. In
> > > time I
> > > > can review the code and see if I can consolidate/optimize
> > parts of
> > > it as
> > > > well.
> > > >
> > > > I'm not sure I understand why XML and Dictionary (or AMF
> > equivalents)
> > > > can't be implemented as IExternalizable, but I haven't
> dug deep
> > > enough to
> > > > know.
> > > >
> > > > I can understand why you thought about this approach,
> but I
> > don't
> > > think it
> > > > is viable. I have been digging kinda deep in this for a
> while
> > now.
> > > That
> > > > doesn't mean I have not thought of all angles, but I can
> say
> > that I
> > > have
> > > > spent a bit of time thinking about it. If you want to
> discuss
> > it
> > > more, feel
> > > > free to open a thread about that and we can both dig
> deeper.
> > > >
> > > >
> > > >
> > > > On Fri, Mar 8, 2019 at 11:29 AM Alex Harui
> > <aharui@adobe.com.invalid
> > > >
> > > > wrote:
> > > >
> > > >> Royale has a JSONReviver that is a first cut at
> generating
> > > ValueObjects
> > > >> from JSON.
> > > >>
> > > >> What we don't know is what the relative
> performance/bandwidth
> > > trade-offs
> > > >> are on AMF vs JSON. However, it really shouldn't
> matter.
> > Royale
> > > can offer
> > > >> both. I'm just wanting the implementation of AMF
> support in
> > XML to
> > > be
> > > >> PAYG. I'm not concerned about download size of AMF code
> > unless
> > > support for
> > > >> lesser-used classes are significant.
> > > >>
> > > >> I'm not sure I understand why XML and Dictionary (or AMF
> > > equivalents)
> > > >> can't be implemented as IExternalizable, but I haven't
> dug
> > deep
> > > enough to
> > > >> know.
> > > >>
> > > >> Thanks,
> > > >> -Alex
> > > >>
> > > >> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com>
> wrote:
> > > >>
> > > >> Sure Carlos, that's just my view.
> > > >> There are definitely more approaches to 'typing'
> json than
> > > there used
> > > >> to be
> > > >> (I did not use protobuffer yet but it seems
> interesting).
> > I
> > > think the
> > > >> case
> > > >> for AMF becomes stronger for 'new' projects if
> there is
> > an easy
> > > way
> > > >> to move
> > > >> to other things without major changes.
> > > >> But for the record I do like amf :)
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
> > > >> carlosrovira@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Hi Greg
> > > >> >
> > > >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<
> > > greg.dove@gmail.com>)
> > > >> > escribió:
> > > >> >
> > > >> > >
> > > >> > > 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.
> > > >> > >
> > > >> > >
> > > >> > don't want to "un-focus" the thread, but I
> continue
> > thinking
> > > that
> > > >> AMF is
> > > >> > far better for structured programing.
> > > >> > JSON still lacks typing, and that seems to me a
> big
> > problem.
> > > >> > Maybe speed, nowadays could be almost the same
> > (although I
> > > think
> > > >> when I
> > > >> > search about this topic few months ago that AMF
> still
> > was more
> > > >> performant)
> > > >> > So, if people uses Royale, and AMF is working
> great as
> > we have
> > > >> now...don't
> > > >> > see a reason to not go with AMF as a first option.
> > > >> >
> > > >> > Just my 2! ;)
> > > >> >
> > > >> >
> > > >> > > --
> > > >> > > Carlos Rovira
> > > >> > >
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C20601e4269a74549d13b08d6b5a2b2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636896107763678068&sdata=ZyDtKNnoy0axqllseYl4poplJqBal9euvyxDPhe7GoI%3D&reserved=0
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: AMF updates
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Feel free to make subclass of ArrayList in Express that has IExternalizable code for enterprise grade development. Or create a new SWC for enterprise grade stuff. Royale's Basic should serve folks trying to make small apps that are not necessarily enterprise grade. That's why we are trying to promote PAYG throughout the framework. I expect in the end that other SWCs besides Basic will be more popular (Jewel, Express or some new Enterprise SWC), but we want Basic to be around for the folks who are trying to shrink something down or speed something up.
Thanks,
-Alex
On 3/30/19, 11:32 PM, "Greg Dove" <gr...@gmail.com> wrote:
I see it now, I had not noticed that before.... it is not present in the
maven build so maybe I did not correctly set up the dependency order for
ant, sorry. I will take a look at it tomorrow my time.
In terms of ArrayList and IExternalizable, is it not reasonable to assume
that serialization will be useful in the general case, for enterprise grade
development?
IExternalizable is useful for amf now, but it could be harnessed, I
believe, for other types of serialization, like custom json which includes
type data etc (it won't be as compact as amf, but maybe it could be faster
to encode/decode and easy to build serverside support for it).
On Sun, Mar 31, 2019 at 6:47 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Is anybody else seeing this warning when building Basic .swc?
>
> Warning: The definition org.apache.royale.net.utils.IExternalizable
> depended on by org.apache.royale.collections.ArrayList in the SWC
> /Users/aharui/git/royale/ant/royale-asjs/frameworks/libs/Collections.swc
> could not be found
>
> IMO, ArrayList should not implement IExternalizable for PAYG reasons.
> Some subclass should. And that would likely resolve the build order issue.
>
> Thanks,
> -Alex
>
> On 3/7/19, 5:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 'I thought that even native AS types (int, number, string) essentially
> had
> a class alias in the AMF data and thus XML and Dictionary would too.'
>
> I expect they probably have actual traits information in the avm
> implementation for more general purposes and for consistency. But
> these are
> treated specially and are not amf encoded with traits info. This means
> that
> registerClassAlias has no effect on the encoding, at least for the
> standard
> types - I did check this in flash with a String test, but did not go
> through all of them. The established serialization/deserialization code
> itself provides the clues for this.
>
> I assume this is done because they are always encoded in what is
> (presumably) the most compact form. As a quick example, a Boolean is
> encoded with one byte that serves both as its type and its value. Any
> implementation using traits or aliasing would be much less compact. So
> each
> of these has their own type codes in AMF, and are treated differently
> to
> other more general objects (including class instances) which *do*
> include
> traits information (or reference it if there has been previous access
> to
> that specific traits) in the serialized format and they do require a
> registered alias to decode back to the class instance instead of
> anonymous
> object.
>
> iirc from experience, there was a need to have the 'generic' type of a
> vector.<Class> aliased, and maybe the Vector<Class> variation aliased
> also,
> because I think these are another case... but that will be for another
> time
> and I will check it then. Vector<int>, <uint> and <Number> are also
> special-cased, and I also expect they will ignore aliasing, because it
> would only add unnecessary weight to the encoded content. But I will
> look
> in the tamarin code when I get to that (we need a concrete Vector
> implementation first, or at least some way to tag the Array instances
> that
> represent Vectors for runtime checks).
>
>
>
>
>
> On Fri, Mar 8, 2019 at 1:05 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Well, maybe you can answer this one question:
> >
> > I thought that even native AS types (int, number, string)
> essentially had
> > a class alias in the AMF data and thus XML and Dictionary would
> too. And
> > then in theory, anyone could change the class alias map to map the
> alias
> > for XML to something else. How are native types represented in AMF
> data?
> > How does the decode know it is a String, int, Number or XML?
> >
> > Thanks,
> > -Alex
> >
> > On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > Correction: That doesn't mean I *have* thought ...etc
> >
> > On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com>
> wrote:
> >
> > > I'm not concerned about download size of AMF code unless
> support for
> > > lesser-used classes are significant.
> > >
> > > OK, so I think I have that. XML is very PAYG. It only works for
> > writing if
> > > you use XML already elsewhere in your project (if you did not
> do
> > that, then
> > > you could never write an XML instance in any case!). And it
> throws
> > errors
> > > if XML is needed for reading, but not included in your
> project. In
> > time I
> > > can review the code and see if I can consolidate/optimize
> parts of
> > it as
> > > well.
> > >
> > > I'm not sure I understand why XML and Dictionary (or AMF
> equivalents)
> > > can't be implemented as IExternalizable, but I haven't dug deep
> > enough to
> > > know.
> > >
> > > I can understand why you thought about this approach, but I
> don't
> > think it
> > > is viable. I have been digging kinda deep in this for a while
> now.
> > That
> > > doesn't mean I have not thought of all angles, but I can say
> that I
> > have
> > > spent a bit of time thinking about it. If you want to discuss
> it
> > more, feel
> > > free to open a thread about that and we can both dig deeper.
> > >
> > >
> > >
> > > On Fri, Mar 8, 2019 at 11:29 AM Alex Harui
> <aharui@adobe.com.invalid
> > >
> > > wrote:
> > >
> > >> Royale has a JSONReviver that is a first cut at generating
> > ValueObjects
> > >> from JSON.
> > >>
> > >> What we don't know is what the relative performance/bandwidth
> > trade-offs
> > >> are on AMF vs JSON. However, it really shouldn't matter.
> Royale
> > can offer
> > >> both. I'm just wanting the implementation of AMF support in
> XML to
> > be
> > >> PAYG. I'm not concerned about download size of AMF code
> unless
> > support for
> > >> lesser-used classes are significant.
> > >>
> > >> I'm not sure I understand why XML and Dictionary (or AMF
> > equivalents)
> > >> can't be implemented as IExternalizable, but I haven't dug
> deep
> > enough to
> > >> know.
> > >>
> > >> Thanks,
> > >> -Alex
> > >>
> > >> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
> > >>
> > >> Sure Carlos, that's just my view.
> > >> There are definitely more approaches to 'typing' json than
> > there used
> > >> to be
> > >> (I did not use protobuffer yet but it seems interesting).
> I
> > think the
> > >> case
> > >> for AMF becomes stronger for 'new' projects if there is
> an easy
> > way
> > >> to move
> > >> to other things without major changes.
> > >> But for the record I do like amf :)
> > >>
> > >>
> > >>
> > >> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
> > >> carlosrovira@apache.org>
> > >> wrote:
> > >>
> > >> > Hi Greg
> > >> >
> > >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<
> > greg.dove@gmail.com>)
> > >> > escribió:
> > >> >
> > >> > >
> > >> > > 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.
> > >> > >
> > >> > >
> > >> > don't want to "un-focus" the thread, but I continue
> thinking
> > that
> > >> AMF is
> > >> > far better for structured programing.
> > >> > JSON still lacks typing, and that seems to me a big
> problem.
> > >> > Maybe speed, nowadays could be almost the same
> (although I
> > think
> > >> when I
> > >> > search about this topic few months ago that AMF still
> was more
> > >> performant)
> > >> > So, if people uses Royale, and AMF is working great as
> we have
> > >> now...don't
> > >> > see a reason to not go with AMF as a first option.
> > >> >
> > >> > Just my 2! ;)
> > >> >
> > >> >
> > >> > > --
> > >> > > Carlos Rovira
> > >> > >
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C20601e4269a74549d13b08d6b5a2b2ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636896107763678068&sdata=ZyDtKNnoy0axqllseYl4poplJqBal9euvyxDPhe7GoI%3D&reserved=0
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
I see it now, I had not noticed that before.... it is not present in the
maven build so maybe I did not correctly set up the dependency order for
ant, sorry. I will take a look at it tomorrow my time.
In terms of ArrayList and IExternalizable, is it not reasonable to assume
that serialization will be useful in the general case, for enterprise grade
development?
IExternalizable is useful for amf now, but it could be harnessed, I
believe, for other types of serialization, like custom json which includes
type data etc (it won't be as compact as amf, but maybe it could be faster
to encode/decode and easy to build serverside support for it).
On Sun, Mar 31, 2019 at 6:47 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Is anybody else seeing this warning when building Basic .swc?
>
> Warning: The definition org.apache.royale.net.utils.IExternalizable
> depended on by org.apache.royale.collections.ArrayList in the SWC
> /Users/aharui/git/royale/ant/royale-asjs/frameworks/libs/Collections.swc
> could not be found
>
> IMO, ArrayList should not implement IExternalizable for PAYG reasons.
> Some subclass should. And that would likely resolve the build order issue.
>
> Thanks,
> -Alex
>
> On 3/7/19, 5:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 'I thought that even native AS types (int, number, string) essentially
> had
> a class alias in the AMF data and thus XML and Dictionary would too.'
>
> I expect they probably have actual traits information in the avm
> implementation for more general purposes and for consistency. But
> these are
> treated specially and are not amf encoded with traits info. This means
> that
> registerClassAlias has no effect on the encoding, at least for the
> standard
> types - I did check this in flash with a String test, but did not go
> through all of them. The established serialization/deserialization code
> itself provides the clues for this.
>
> I assume this is done because they are always encoded in what is
> (presumably) the most compact form. As a quick example, a Boolean is
> encoded with one byte that serves both as its type and its value. Any
> implementation using traits or aliasing would be much less compact. So
> each
> of these has their own type codes in AMF, and are treated differently
> to
> other more general objects (including class instances) which *do*
> include
> traits information (or reference it if there has been previous access
> to
> that specific traits) in the serialized format and they do require a
> registered alias to decode back to the class instance instead of
> anonymous
> object.
>
> iirc from experience, there was a need to have the 'generic' type of a
> vector.<Class> aliased, and maybe the Vector<Class> variation aliased
> also,
> because I think these are another case... but that will be for another
> time
> and I will check it then. Vector<int>, <uint> and <Number> are also
> special-cased, and I also expect they will ignore aliasing, because it
> would only add unnecessary weight to the encoded content. But I will
> look
> in the tamarin code when I get to that (we need a concrete Vector
> implementation first, or at least some way to tag the Array instances
> that
> represent Vectors for runtime checks).
>
>
>
>
>
> On Fri, Mar 8, 2019 at 1:05 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Well, maybe you can answer this one question:
> >
> > I thought that even native AS types (int, number, string)
> essentially had
> > a class alias in the AMF data and thus XML and Dictionary would
> too. And
> > then in theory, anyone could change the class alias map to map the
> alias
> > for XML to something else. How are native types represented in AMF
> data?
> > How does the decode know it is a String, int, Number or XML?
> >
> > Thanks,
> > -Alex
> >
> > On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > Correction: That doesn't mean I *have* thought ...etc
> >
> > On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com>
> wrote:
> >
> > > I'm not concerned about download size of AMF code unless
> support for
> > > lesser-used classes are significant.
> > >
> > > OK, so I think I have that. XML is very PAYG. It only works for
> > writing if
> > > you use XML already elsewhere in your project (if you did not
> do
> > that, then
> > > you could never write an XML instance in any case!). And it
> throws
> > errors
> > > if XML is needed for reading, but not included in your
> project. In
> > time I
> > > can review the code and see if I can consolidate/optimize
> parts of
> > it as
> > > well.
> > >
> > > I'm not sure I understand why XML and Dictionary (or AMF
> equivalents)
> > > can't be implemented as IExternalizable, but I haven't dug deep
> > enough to
> > > know.
> > >
> > > I can understand why you thought about this approach, but I
> don't
> > think it
> > > is viable. I have been digging kinda deep in this for a while
> now.
> > That
> > > doesn't mean I have not thought of all angles, but I can say
> that I
> > have
> > > spent a bit of time thinking about it. If you want to discuss
> it
> > more, feel
> > > free to open a thread about that and we can both dig deeper.
> > >
> > >
> > >
> > > On Fri, Mar 8, 2019 at 11:29 AM Alex Harui
> <aharui@adobe.com.invalid
> > >
> > > wrote:
> > >
> > >> Royale has a JSONReviver that is a first cut at generating
> > ValueObjects
> > >> from JSON.
> > >>
> > >> What we don't know is what the relative performance/bandwidth
> > trade-offs
> > >> are on AMF vs JSON. However, it really shouldn't matter.
> Royale
> > can offer
> > >> both. I'm just wanting the implementation of AMF support in
> XML to
> > be
> > >> PAYG. I'm not concerned about download size of AMF code
> unless
> > support for
> > >> lesser-used classes are significant.
> > >>
> > >> I'm not sure I understand why XML and Dictionary (or AMF
> > equivalents)
> > >> can't be implemented as IExternalizable, but I haven't dug
> deep
> > enough to
> > >> know.
> > >>
> > >> Thanks,
> > >> -Alex
> > >>
> > >> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
> > >>
> > >> Sure Carlos, that's just my view.
> > >> There are definitely more approaches to 'typing' json than
> > there used
> > >> to be
> > >> (I did not use protobuffer yet but it seems interesting).
> I
> > think the
> > >> case
> > >> for AMF becomes stronger for 'new' projects if there is
> an easy
> > way
> > >> to move
> > >> to other things without major changes.
> > >> But for the record I do like amf :)
> > >>
> > >>
> > >>
> > >> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
> > >> carlosrovira@apache.org>
> > >> wrote:
> > >>
> > >> > Hi Greg
> > >> >
> > >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<
> > greg.dove@gmail.com>)
> > >> > escribió:
> > >> >
> > >> > >
> > >> > > 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.
> > >> > >
> > >> > >
> > >> > don't want to "un-focus" the thread, but I continue
> thinking
> > that
> > >> AMF is
> > >> > far better for structured programing.
> > >> > JSON still lacks typing, and that seems to me a big
> problem.
> > >> > Maybe speed, nowadays could be almost the same
> (although I
> > think
> > >> when I
> > >> > search about this topic few months ago that AMF still
> was more
> > >> performant)
> > >> > So, if people uses Royale, and AMF is working great as
> we have
> > >> now...don't
> > >> > see a reason to not go with AMF as a first option.
> > >> >
> > >> > Just my 2! ;)
> > >> >
> > >> >
> > >> > > --
> > >> > > Carlos Rovira
> > >> > >
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7abd857e950f4ba0525108d6a3661c06%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636876056285620759&sdata=uNKl4Ik7arHDhy%2B9kTboSHkqbSKgFx7KGet%2B9N%2BlOGI%3D&reserved=0
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: AMF updates
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Is anybody else seeing this warning when building Basic .swc?
Warning: The definition org.apache.royale.net.utils.IExternalizable depended on by org.apache.royale.collections.ArrayList in the SWC /Users/aharui/git/royale/ant/royale-asjs/frameworks/libs/Collections.swc could not be found
IMO, ArrayList should not implement IExternalizable for PAYG reasons. Some subclass should. And that would likely resolve the build order issue.
Thanks,
-Alex
On 3/7/19, 5:33 PM, "Greg Dove" <gr...@gmail.com> wrote:
'I thought that even native AS types (int, number, string) essentially had
a class alias in the AMF data and thus XML and Dictionary would too.'
I expect they probably have actual traits information in the avm
implementation for more general purposes and for consistency. But these are
treated specially and are not amf encoded with traits info. This means that
registerClassAlias has no effect on the encoding, at least for the standard
types - I did check this in flash with a String test, but did not go
through all of them. The established serialization/deserialization code
itself provides the clues for this.
I assume this is done because they are always encoded in what is
(presumably) the most compact form. As a quick example, a Boolean is
encoded with one byte that serves both as its type and its value. Any
implementation using traits or aliasing would be much less compact. So each
of these has their own type codes in AMF, and are treated differently to
other more general objects (including class instances) which *do* include
traits information (or reference it if there has been previous access to
that specific traits) in the serialized format and they do require a
registered alias to decode back to the class instance instead of anonymous
object.
iirc from experience, there was a need to have the 'generic' type of a
vector.<Class> aliased, and maybe the Vector<Class> variation aliased also,
because I think these are another case... but that will be for another time
and I will check it then. Vector<int>, <uint> and <Number> are also
special-cased, and I also expect they will ignore aliasing, because it
would only add unnecessary weight to the encoded content. But I will look
in the tamarin code when I get to that (we need a concrete Vector
implementation first, or at least some way to tag the Array instances that
represent Vectors for runtime checks).
On Fri, Mar 8, 2019 at 1:05 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Well, maybe you can answer this one question:
>
> I thought that even native AS types (int, number, string) essentially had
> a class alias in the AMF data and thus XML and Dictionary would too. And
> then in theory, anyone could change the class alias map to map the alias
> for XML to something else. How are native types represented in AMF data?
> How does the decode know it is a String, int, Number or XML?
>
> Thanks,
> -Alex
>
> On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Correction: That doesn't mean I *have* thought ...etc
>
> On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com> wrote:
>
> > I'm not concerned about download size of AMF code unless support for
> > lesser-used classes are significant.
> >
> > OK, so I think I have that. XML is very PAYG. It only works for
> writing if
> > you use XML already elsewhere in your project (if you did not do
> that, then
> > you could never write an XML instance in any case!). And it throws
> errors
> > if XML is needed for reading, but not included in your project. In
> time I
> > can review the code and see if I can consolidate/optimize parts of
> it as
> > well.
> >
> > I'm not sure I understand why XML and Dictionary (or AMF equivalents)
> > can't be implemented as IExternalizable, but I haven't dug deep
> enough to
> > know.
> >
> > I can understand why you thought about this approach, but I don't
> think it
> > is viable. I have been digging kinda deep in this for a while now.
> That
> > doesn't mean I have not thought of all angles, but I can say that I
> have
> > spent a bit of time thinking about it. If you want to discuss it
> more, feel
> > free to open a thread about that and we can both dig deeper.
> >
> >
> >
> > On Fri, Mar 8, 2019 at 11:29 AM Alex Harui <aharui@adobe.com.invalid
> >
> > wrote:
> >
> >> Royale has a JSONReviver that is a first cut at generating
> ValueObjects
> >> from JSON.
> >>
> >> What we don't know is what the relative performance/bandwidth
> trade-offs
> >> are on AMF vs JSON. However, it really shouldn't matter. Royale
> can offer
> >> both. I'm just wanting the implementation of AMF support in XML to
> be
> >> PAYG. I'm not concerned about download size of AMF code unless
> support for
> >> lesser-used classes are significant.
> >>
> >> I'm not sure I understand why XML and Dictionary (or AMF
> equivalents)
> >> can't be implemented as IExternalizable, but I haven't dug deep
> enough to
> >> know.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> Sure Carlos, that's just my view.
> >> There are definitely more approaches to 'typing' json than
> there used
> >> to be
> >> (I did not use protobuffer yet but it seems interesting). I
> think the
> >> case
> >> for AMF becomes stronger for 'new' projects if there is an easy
> way
> >> to move
> >> to other things without major changes.
> >> But for the record I do like amf :)
> >>
> >>
> >>
> >> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
> >> carlosrovira@apache.org>
> >> wrote:
> >>
> >> > Hi Greg
> >> >
> >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<
> greg.dove@gmail.com>)
> >> > escribió:
> >> >
> >> > >
> >> > > 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.
> >> > >
> >> > >
> >> > don't want to "un-focus" the thread, but I continue thinking
> that
> >> AMF is
> >> > far better for structured programing.
> >> > JSON still lacks typing, and that seems to me a big problem.
> >> > Maybe speed, nowadays could be almost the same (although I
> think
> >> when I
> >> > search about this topic few months ago that AMF still was more
> >> performant)
> >> > So, if people uses Royale, and AMF is working great as we have
> >> now...don't
> >> > see a reason to not go with AMF as a first option.
> >> >
> >> > Just my 2! ;)
> >> >
> >> >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7abd857e950f4ba0525108d6a3661c06%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636876056285620759&sdata=uNKl4Ik7arHDhy%2B9kTboSHkqbSKgFx7KGet%2B9N%2BlOGI%3D&reserved=0
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
>
>
>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
'I thought that even native AS types (int, number, string) essentially had
a class alias in the AMF data and thus XML and Dictionary would too.'
I expect they probably have actual traits information in the avm
implementation for more general purposes and for consistency. But these are
treated specially and are not amf encoded with traits info. This means that
registerClassAlias has no effect on the encoding, at least for the standard
types - I did check this in flash with a String test, but did not go
through all of them. The established serialization/deserialization code
itself provides the clues for this.
I assume this is done because they are always encoded in what is
(presumably) the most compact form. As a quick example, a Boolean is
encoded with one byte that serves both as its type and its value. Any
implementation using traits or aliasing would be much less compact. So each
of these has their own type codes in AMF, and are treated differently to
other more general objects (including class instances) which *do* include
traits information (or reference it if there has been previous access to
that specific traits) in the serialized format and they do require a
registered alias to decode back to the class instance instead of anonymous
object.
iirc from experience, there was a need to have the 'generic' type of a
vector.<Class> aliased, and maybe the Vector<Class> variation aliased also,
because I think these are another case... but that will be for another time
and I will check it then. Vector<int>, <uint> and <Number> are also
special-cased, and I also expect they will ignore aliasing, because it
would only add unnecessary weight to the encoded content. But I will look
in the tamarin code when I get to that (we need a concrete Vector
implementation first, or at least some way to tag the Array instances that
represent Vectors for runtime checks).
On Fri, Mar 8, 2019 at 1:05 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Well, maybe you can answer this one question:
>
> I thought that even native AS types (int, number, string) essentially had
> a class alias in the AMF data and thus XML and Dictionary would too. And
> then in theory, anyone could change the class alias map to map the alias
> for XML to something else. How are native types represented in AMF data?
> How does the decode know it is a String, int, Number or XML?
>
> Thanks,
> -Alex
>
> On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Correction: That doesn't mean I *have* thought ...etc
>
> On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com> wrote:
>
> > I'm not concerned about download size of AMF code unless support for
> > lesser-used classes are significant.
> >
> > OK, so I think I have that. XML is very PAYG. It only works for
> writing if
> > you use XML already elsewhere in your project (if you did not do
> that, then
> > you could never write an XML instance in any case!). And it throws
> errors
> > if XML is needed for reading, but not included in your project. In
> time I
> > can review the code and see if I can consolidate/optimize parts of
> it as
> > well.
> >
> > I'm not sure I understand why XML and Dictionary (or AMF equivalents)
> > can't be implemented as IExternalizable, but I haven't dug deep
> enough to
> > know.
> >
> > I can understand why you thought about this approach, but I don't
> think it
> > is viable. I have been digging kinda deep in this for a while now.
> That
> > doesn't mean I have not thought of all angles, but I can say that I
> have
> > spent a bit of time thinking about it. If you want to discuss it
> more, feel
> > free to open a thread about that and we can both dig deeper.
> >
> >
> >
> > On Fri, Mar 8, 2019 at 11:29 AM Alex Harui <aharui@adobe.com.invalid
> >
> > wrote:
> >
> >> Royale has a JSONReviver that is a first cut at generating
> ValueObjects
> >> from JSON.
> >>
> >> What we don't know is what the relative performance/bandwidth
> trade-offs
> >> are on AMF vs JSON. However, it really shouldn't matter. Royale
> can offer
> >> both. I'm just wanting the implementation of AMF support in XML to
> be
> >> PAYG. I'm not concerned about download size of AMF code unless
> support for
> >> lesser-used classes are significant.
> >>
> >> I'm not sure I understand why XML and Dictionary (or AMF
> equivalents)
> >> can't be implemented as IExternalizable, but I haven't dug deep
> enough to
> >> know.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> Sure Carlos, that's just my view.
> >> There are definitely more approaches to 'typing' json than
> there used
> >> to be
> >> (I did not use protobuffer yet but it seems interesting). I
> think the
> >> case
> >> for AMF becomes stronger for 'new' projects if there is an easy
> way
> >> to move
> >> to other things without major changes.
> >> But for the record I do like amf :)
> >>
> >>
> >>
> >> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
> >> carlosrovira@apache.org>
> >> wrote:
> >>
> >> > Hi Greg
> >> >
> >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<
> greg.dove@gmail.com>)
> >> > escribió:
> >> >
> >> > >
> >> > > 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.
> >> > >
> >> > >
> >> > don't want to "un-focus" the thread, but I continue thinking
> that
> >> AMF is
> >> > far better for structured programing.
> >> > JSON still lacks typing, and that seems to me a big problem.
> >> > Maybe speed, nowadays could be almost the same (although I
> think
> >> when I
> >> > search about this topic few months ago that AMF still was more
> >> performant)
> >> > So, if people uses Royale, and AMF is working great as we have
> >> now...don't
> >> > see a reason to not go with AMF as a first option.
> >> >
> >> > Just my 2! ;)
> >> >
> >> >
> >> > > --
> >> > > Carlos Rovira
> >> > >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb0d52d1367c4a8697c308d6a357805e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875993544273290&sdata=f1rl%2Fj7EUyHD297Le2TmqT5VhIJT4Gn8juPYWJs2s5k%3D&reserved=0
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
>
>
>
Re: AMF updates
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Well, maybe you can answer this one question:
I thought that even native AS types (int, number, string) essentially had a class alias in the AMF data and thus XML and Dictionary would too. And then in theory, anyone could change the class alias map to map the alias for XML to something else. How are native types represented in AMF data? How does the decode know it is a String, int, Number or XML?
Thanks,
-Alex
On 3/7/19, 3:49 PM, "Greg Dove" <gr...@gmail.com> wrote:
Correction: That doesn't mean I *have* thought ...etc
On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com> wrote:
> I'm not concerned about download size of AMF code unless support for
> lesser-used classes are significant.
>
> OK, so I think I have that. XML is very PAYG. It only works for writing if
> you use XML already elsewhere in your project (if you did not do that, then
> you could never write an XML instance in any case!). And it throws errors
> if XML is needed for reading, but not included in your project. In time I
> can review the code and see if I can consolidate/optimize parts of it as
> well.
>
> I'm not sure I understand why XML and Dictionary (or AMF equivalents)
> can't be implemented as IExternalizable, but I haven't dug deep enough to
> know.
>
> I can understand why you thought about this approach, but I don't think it
> is viable. I have been digging kinda deep in this for a while now. That
> doesn't mean I have not thought of all angles, but I can say that I have
> spent a bit of time thinking about it. If you want to discuss it more, feel
> free to open a thread about that and we can both dig deeper.
>
>
>
> On Fri, Mar 8, 2019 at 11:29 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> Royale has a JSONReviver that is a first cut at generating ValueObjects
>> from JSON.
>>
>> What we don't know is what the relative performance/bandwidth trade-offs
>> are on AMF vs JSON. However, it really shouldn't matter. Royale can offer
>> both. I'm just wanting the implementation of AMF support in XML to be
>> PAYG. I'm not concerned about download size of AMF code unless support for
>> lesser-used classes are significant.
>>
>> I'm not sure I understand why XML and Dictionary (or AMF equivalents)
>> can't be implemented as IExternalizable, but I haven't dug deep enough to
>> know.
>>
>> Thanks,
>> -Alex
>>
>> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Sure Carlos, that's just my view.
>> There are definitely more approaches to 'typing' json than there used
>> to be
>> (I did not use protobuffer yet but it seems interesting). I think the
>> case
>> for AMF becomes stronger for 'new' projects if there is an easy way
>> to move
>> to other things without major changes.
>> But for the record I do like amf :)
>>
>>
>>
>> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
>> carlosrovira@apache.org>
>> wrote:
>>
>> > Hi Greg
>> >
>> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
>> > escribió:
>> >
>> > >
>> > > 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.
>> > >
>> > >
>> > don't want to "un-focus" the thread, but I continue thinking that
>> AMF is
>> > far better for structured programing.
>> > JSON still lacks typing, and that seems to me a big problem.
>> > Maybe speed, nowadays could be almost the same (although I think
>> when I
>> > search about this topic few months ago that AMF still was more
>> performant)
>> > So, if people uses Royale, and AMF is working great as we have
>> now...don't
>> > see a reason to not go with AMF as a first option.
>> >
>> > Just my 2! ;)
>> >
>> >
>> > > --
>> > > Carlos Rovira
>> > >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb0d52d1367c4a8697c308d6a357805e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875993544273290&sdata=f1rl%2Fj7EUyHD297Le2TmqT5VhIJT4Gn8juPYWJs2s5k%3D&reserved=0
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
Correction: That doesn't mean I *have* thought ...etc
On Fri, Mar 8, 2019 at 12:41 PM Greg Dove <gr...@gmail.com> wrote:
> I'm not concerned about download size of AMF code unless support for
> lesser-used classes are significant.
>
> OK, so I think I have that. XML is very PAYG. It only works for writing if
> you use XML already elsewhere in your project (if you did not do that, then
> you could never write an XML instance in any case!). And it throws errors
> if XML is needed for reading, but not included in your project. In time I
> can review the code and see if I can consolidate/optimize parts of it as
> well.
>
> I'm not sure I understand why XML and Dictionary (or AMF equivalents)
> can't be implemented as IExternalizable, but I haven't dug deep enough to
> know.
>
> I can understand why you thought about this approach, but I don't think it
> is viable. I have been digging kinda deep in this for a while now. That
> doesn't mean I have not thought of all angles, but I can say that I have
> spent a bit of time thinking about it. If you want to discuss it more, feel
> free to open a thread about that and we can both dig deeper.
>
>
>
> On Fri, Mar 8, 2019 at 11:29 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> Royale has a JSONReviver that is a first cut at generating ValueObjects
>> from JSON.
>>
>> What we don't know is what the relative performance/bandwidth trade-offs
>> are on AMF vs JSON. However, it really shouldn't matter. Royale can offer
>> both. I'm just wanting the implementation of AMF support in XML to be
>> PAYG. I'm not concerned about download size of AMF code unless support for
>> lesser-used classes are significant.
>>
>> I'm not sure I understand why XML and Dictionary (or AMF equivalents)
>> can't be implemented as IExternalizable, but I haven't dug deep enough to
>> know.
>>
>> Thanks,
>> -Alex
>>
>> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Sure Carlos, that's just my view.
>> There are definitely more approaches to 'typing' json than there used
>> to be
>> (I did not use protobuffer yet but it seems interesting). I think the
>> case
>> for AMF becomes stronger for 'new' projects if there is an easy way
>> to move
>> to other things without major changes.
>> But for the record I do like amf :)
>>
>>
>>
>> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <
>> carlosrovira@apache.org>
>> wrote:
>>
>> > Hi Greg
>> >
>> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
>> > escribió:
>> >
>> > >
>> > > 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.
>> > >
>> > >
>> > don't want to "un-focus" the thread, but I continue thinking that
>> AMF is
>> > far better for structured programing.
>> > JSON still lacks typing, and that seems to me a big problem.
>> > Maybe speed, nowadays could be almost the same (although I think
>> when I
>> > search about this topic few months ago that AMF still was more
>> performant)
>> > So, if people uses Royale, and AMF is working great as we have
>> now...don't
>> > see a reason to not go with AMF as a first option.
>> >
>> > Just my 2! ;)
>> >
>> >
>> > > --
>> > > Carlos Rovira
>> > >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C354e11257b4d4f0a0f4808d6a34b3fae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875940924004950&sdata=Sx1Ky8BKMOesHO9t5apR6iXm21XoRQFHTQSCUqOPt9k%3D&reserved=0
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
I'm not concerned about download size of AMF code unless support for
lesser-used classes are significant.
OK, so I think I have that. XML is very PAYG. It only works for writing if
you use XML already elsewhere in your project (if you did not do that, then
you could never write an XML instance in any case!). And it throws errors
if XML is needed for reading, but not included in your project. In time I
can review the code and see if I can consolidate/optimize parts of it as
well.
I'm not sure I understand why XML and Dictionary (or AMF equivalents) can't
be implemented as IExternalizable, but I haven't dug deep enough to know.
I can understand why you thought about this approach, but I don't think it
is viable. I have been digging kinda deep in this for a while now. That
doesn't mean I have not thought of all angles, but I can say that I have
spent a bit of time thinking about it. If you want to discuss it more, feel
free to open a thread about that and we can both dig deeper.
On Fri, Mar 8, 2019 at 11:29 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Royale has a JSONReviver that is a first cut at generating ValueObjects
> from JSON.
>
> What we don't know is what the relative performance/bandwidth trade-offs
> are on AMF vs JSON. However, it really shouldn't matter. Royale can offer
> both. I'm just wanting the implementation of AMF support in XML to be
> PAYG. I'm not concerned about download size of AMF code unless support for
> lesser-used classes are significant.
>
> I'm not sure I understand why XML and Dictionary (or AMF equivalents)
> can't be implemented as IExternalizable, but I haven't dug deep enough to
> know.
>
> Thanks,
> -Alex
>
> On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Sure Carlos, that's just my view.
> There are definitely more approaches to 'typing' json than there used
> to be
> (I did not use protobuffer yet but it seems interesting). I think the
> case
> for AMF becomes stronger for 'new' projects if there is an easy way to
> move
> to other things without major changes.
> But for the record I do like amf :)
>
>
>
> On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <carlosrovira@apache.org
> >
> wrote:
>
> > Hi Greg
> >
> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
> > escribió:
> >
> > >
> > > 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.
> > >
> > >
> > don't want to "un-focus" the thread, but I continue thinking that
> AMF is
> > far better for structured programing.
> > JSON still lacks typing, and that seems to me a big problem.
> > Maybe speed, nowadays could be almost the same (although I think
> when I
> > search about this topic few months ago that AMF still was more
> performant)
> > So, if people uses Royale, and AMF is working great as we have
> now...don't
> > see a reason to not go with AMF as a first option.
> >
> > Just my 2! ;)
> >
> >
> > > --
> > > Carlos Rovira
> > >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C354e11257b4d4f0a0f4808d6a34b3fae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875940924004950&sdata=Sx1Ky8BKMOesHO9t5apR6iXm21XoRQFHTQSCUqOPt9k%3D&reserved=0
> > >
> > >
> > >
> > >
> >
>
>
>
Re: AMF updates
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Royale has a JSONReviver that is a first cut at generating ValueObjects from JSON.
What we don't know is what the relative performance/bandwidth trade-offs are on AMF vs JSON. However, it really shouldn't matter. Royale can offer both. I'm just wanting the implementation of AMF support in XML to be PAYG. I'm not concerned about download size of AMF code unless support for lesser-used classes are significant.
I'm not sure I understand why XML and Dictionary (or AMF equivalents) can't be implemented as IExternalizable, but I haven't dug deep enough to know.
Thanks,
-Alex
On 3/7/19, 2:21 PM, "Greg Dove" <gr...@gmail.com> wrote:
Sure Carlos, that's just my view.
There are definitely more approaches to 'typing' json than there used to be
(I did not use protobuffer yet but it seems interesting). I think the case
for AMF becomes stronger for 'new' projects if there is an easy way to move
to other things without major changes.
But for the record I do like amf :)
On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Greg
>
> El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> >
> > 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.
> >
> >
> don't want to "un-focus" the thread, but I continue thinking that AMF is
> far better for structured programing.
> JSON still lacks typing, and that seems to me a big problem.
> Maybe speed, nowadays could be almost the same (although I think when I
> search about this topic few months ago that AMF still was more performant)
> So, if people uses Royale, and AMF is working great as we have now...don't
> see a reason to not go with AMF as a first option.
>
> Just my 2! ;)
>
>
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C354e11257b4d4f0a0f4808d6a34b3fae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636875940924004950&sdata=Sx1Ky8BKMOesHO9t5apR6iXm21XoRQFHTQSCUqOPt9k%3D&reserved=0
> >
> >
> >
> >
>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
Sure Carlos, that's just my view.
There are definitely more approaches to 'typing' json than there used to be
(I did not use protobuffer yet but it seems interesting). I think the case
for AMF becomes stronger for 'new' projects if there is an easy way to move
to other things without major changes.
But for the record I do like amf :)
On Fri, Mar 8, 2019 at 10:17 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Greg
>
> El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> >
> > 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.
> >
> >
> don't want to "un-focus" the thread, but I continue thinking that AMF is
> far better for structured programing.
> JSON still lacks typing, and that seems to me a big problem.
> Maybe speed, nowadays could be almost the same (although I think when I
> search about this topic few months ago that AMF still was more performant)
> So, if people uses Royale, and AMF is working great as we have now...don't
> see a reason to not go with AMF as a first option.
>
> Just my 2! ;)
>
>
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
> >
> >
>
Re: AMF updates
Posted by Carlos Rovira <ca...@apache.org>.
Hi Greg
El jue., 7 mar. 2019 a las 20:41, Greg Dove (<gr...@gmail.com>)
escribió:
>
> 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.
>
>
don't want to "un-focus" the thread, but I continue thinking that AMF is
far better for structured programing.
JSON still lacks typing, and that seems to me a big problem.
Maybe speed, nowadays could be almost the same (although I think when I
search about this topic few months ago that AMF still was more performant)
So, if people uses Royale, and AMF is working great as we have now...don't
see a reason to not go with AMF as a first option.
Just my 2! ;)
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
>
>
Re: AMF updates
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@gmail.com> wrote:
> I think the changes are OK.
>
> > On Mar 7, 2019, at 3:41 AM, Greg Dove <gr...@gmail.com> 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
>
>
Re: AMF updates
Posted by Harbs <ha...@gmail.com>.
I think the changes are OK.
> On Mar 7, 2019, at 3:41 AM, Greg Dove <gr...@gmail.com> 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
Re: AMF updates
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@adobe.com.invalid>)
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" <gr...@gmail.com> 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
Re: AMF updates
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@gmail.com> 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