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/04/01 03:30:57 UTC
Re: AMF updates
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
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>