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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 > <[email protected]> > > 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" <[email protected]> wrote: > > > > > > Correction: That doesn't mean I *have* thought ...etc > > > > > > On Fri, Mar 8, 2019 at 12:41 PM Greg Dove < > [email protected]> > > 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 > > <[email protected] > > > > > > > > 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" <[email protected]> > 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 < > > > >> [email protected]> > > > >> wrote: > > > >> > > > >> > Hi Greg > > > >> > > > > >> > El jue., 7 mar. 2019 a las 20:41, Greg Dove (< > > > [email protected]>) > > > >> > 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 > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > >
