Hi Jason, It's a shame that the options don't fit for you. If at any time you think that Apache Royale may be an option, do not hesitate to contact us.
We will be happy to talk to you. Thanks and best of wishes. Carlos El sáb., 26 oct. 2019 a las 17:03, Jason Huang (<[email protected]>) escribió: > Thanks guys for everything, > I'm afraid that I could not help you guys that much, anyway best wishes for > all of your hard works. > > Best > Jason > > On Wed, Oct 23, 2019 at 5:11 PM Carlos Rovira <[email protected]> > wrote: > > > Hi, > > > > I think this conversation helped a lot to know interested of each one and > > things we can do in the future. Maybe Jason and Kenny can join forces a > see > > if there's a way to bring WASM to Royale and create something like I > > suggested with the name of "FlashRoyale" that could make current Flash > > projects be compiled with Royale and output WASM (and eventually other > > targets if we can get more interest out there). > > > > About copyrights, I think it's a matter of do a cleaning task and be sure > > of remove any part that could be a problem for Apache and copyrights. In > > fact, I think is an important task no matter where that project is hosted > > since will make it more considered if people don't see possible problems > in > > the future to adopt it for their work for years to come. > > > > If you guys bring WASM to Royale I'll be interested in try if is possible > > to add support for Jewel to target WASM. > > As well people already using Royale could target WASM if the rest of > > libraries get support for it (Basic, Jewel,...) > > > > Talking about future and thinking in making your effort durable over > time. > > I think joining Royale, will make that project make the whole set gain > > traction and be of more valuable and of interest for more people. > > > > > > El mié., 23 oct. 2019 a las 3:53, Alex Harui (<[email protected] > >) > > escribió: > > > > > If Royale is successful, there will be libraries emulating all sorts of > > > platforms and runtimes expecting output in certain languages. Flash > can > > be > > > one of them, but the repo holding the code doesn't have to be at > Apache. > > > Should it be? Don't know for sure. > > > > > > I'm sure that most of SpriteFlexJS is not "de-compiled". However, when > > we > > > last looked there were a few things (I think one was Matrix) that was > > taken > > > verbatim from Adobe's playerglobal.swc (there are a few .as files in > the > > > swc, IIRC). That isn't allowed at Apache. > > > > > > If you do have a better animation model for the web, whether it is > based > > > on Flash or not, it would be great for you to develop it. We'll help > > with > > > a transpiler if you stay with AS3. I personally can't help much more > than > > > that. If you want to host the code at Apache Royale, I think we'd be > ok > > > with that if it is Apache-compatible. > > > > > > HTH, > > > -Alex > > > > > > On 10/22/19, 3:01 PM, "Kenny Lerma" <[email protected]> wrote: > > > > > > Thanks for the info Alex and better clarifying some of Royale's > > > overall goals. I certainly don't expect any of the current > > committers > > > to > > > start working on a Flash API. I'm just more interested in how to > > > integrate > > > a Flash API and if it's even worth it to do so. > > > > > > To me, it sounds like a Flash API should continue to be something > > > totally > > > separate as my goal is to drop in an existing flash project and > > > compile to > > > JS or WASM. The concept of Royale, its libraries, and Flex overall > > is > > > just > > > far removed from Flash and its' targeted use. > > > > > > To be clear on SpriteFlexjs, it's not decompiled code from Adobe > > > playerglobal.swc. We simply copied the skeleton of the class that > > you > > > can > > > get by previewing the swc classes in FlashDevelop along with all > it's > > > comments for code completion in an IDE and then began implementing > > > code. > > > It's just a quick way to set up a class with all the needed > methods, > > > properties and comments. We do need to go through and clean up the > > > comments for sure though since they have Adobe copyright > information. > > > > > > I get the idea of the steering wheel over the reigns, but there > > really > > > isn't a better animation pipeline out there for the web when you > > > combine > > > Adobe Animate and Flash. The speed and flexibility is still > > unmatched. > > > Sure, there is CreateJS, but the performance is very poor and if > you > > > want > > > performance then your graphics have to be turned into bitmaps where > > you > > > lose all flexibility in manipulating your graphics at runtime. > There > > > is > > > nothing better to move to without giving up a lot unfortunately or > > > spending > > > a significant amount of time moving to another platform that > > requires a > > > larger team and/or longer development time. > > > > > > So, the idea is to have a WASM output that allows for flexible > > > graphics and > > > performance, but how we get there is uncertain. As Jason > mentioned, > > > Typescript already has the AssemblyScript compiler for WASM, so > I've > > > considered re-writing SpriteFlexjs in Typescript as a whole new > > > project and > > > moving away from ActionScript all together and maybe some > conversion > > > tools > > > for converting Flash projects to Typescript. However, I far prefer > > the > > > ecosystem of ActionScript and not re-writing all my projects to > > > Typescript. > > > > > > Last thought and a bit off topic, but why are there swcs like > > > "CreateJSJS" > > > and "GoogleMapsJS". These all use "org.apache.royale" naming > > > convention > > > when these are third party libraries with there own naming > > > convention. Why > > > are these not simple stubs as an api for the actual javascript > > > library. I > > > realize these are incomplete, but I've never understood why they > > exist > > > in > > > their current form. > > > > > > Kenny > > > > > > On Tue, Oct 22, 2019 at 1:51 PM Alex Harui > <[email protected] > > > > > > wrote: > > > > > > > First, a technical/factual matter: In Royale, if your code says > > > > org.apache.royale.events.Event, the output is > > > > org.apache.royale.events.Event, not "flash.events.Event". The > SWF > > > > implementation of org.apache.royale.events.Event subclasses > > > > flash.events.Event, and subclasses something else for JS. Class > > > > Hierarchies are not guaranteed to be the same across platforms. > > > However, > > > > there are some exceptions: If you write Array.sortOn, the > compiler > > > does > > > > not output Array.sortOn, it outputs > > > org.apache.royale.utils.Language.sortOn. > > > > > > > > Now to opinion-based matters. As I mentioned in my last post, > the > > > > objective of Flex was to abstract away Flash, so that Flash > > concepts > > > > (timelines, Stage, Sprite, etc) were not the base of everything > > from > > > the > > > > application developer's standpoint. Of course in Flex the Flash > > > Sprite was > > > > the true base of Flex's UIComponent and Flash MovieClip was the > > base > > > of > > > > Flex's SystemManager. But the abstraction layer was meant to be > > > > UIComponent and up. Our goal was for folks to write their Flex > > apps > > > > without ever writing "import flash.x.y". > > > > > > > > For various reasons, many Flex developers went down to the Flash > > API > > > and > > > > used URLLoader instead of HTTPService, and Sprite instead of > > > UIComponent. > > > > That was effectively like writing x86 assembly code in your C++ > > > app. You > > > > can do it, and get performance gains, but the assembly code won't > > be > > > > portable to some other CPU. > > > > > > > > There is no need to discuss whether or not there should be an > open > > > source > > > > emulation of Flash APIs. If you want it, go do it. If you can > do > > > it in an > > > > Apache-compatible way, we would consider hosting it in our repos, > > > but there > > > > is no need for every Royale-compatible library to be housed in > > > Royale. If > > > > we're successful, there will be plenty of third party libraries > > > hosted > > > > elsewhere. In the Flex days, Greensock, and other libraries were > > > hosted > > > > elsewhere. No big deal. > > > > > > > > That said, I think you will have a hard time convincing the > current > > > set of > > > > Royale committers to change what they are doing and work on the > > > Flash API > > > > emulation. I won't because I believe it to be a ton of work, not > > > only now > > > > but into the future if we ever target another > > > runtime/output-language. But > > > > also, I don't know Flash that well. I only know where Flex > touched > > > Flash, > > > > but I have no clue about most of the other Flash APIs. I think > the > > > same is > > > > true of most of the current set of committers. > > > > > > > > Royale's MX emulation will emulate a few popular Flash APIs by > > > renaming > > > > the packages. So flash.net.FocusEvent is now mx.net.FocusEvent. > > We > > > are > > > > doing that so that you know your app is completely migrated when > > > there is > > > > no more "import flash.x.y" in your migrated code. And also, so > we > > > are not > > > > committed to provided EVERY property on flash.x.y, only the ones > > > that Flex > > > > or the migrated app used. That's primarily because we are a > small > > > group of > > > > volunteers. There is no big company like Adobe behind Royale. > > > Adobe does > > > > not currently care whether Royale succeeds or not. They will not > > > put more > > > > engineers on Royale right now. > > > > > > > > I assume that folks like Li Zhi, Kenny, and Jason do know the > Flash > > > API > > > > much better because they coded SWFs using it, so it is your > > > responsibility > > > > to collect enough people who know Flash and work on the > emulation. > > > Getting > > > > the current set of committers to do it may not be nearly as > > > efficient as > > > > finding the right people who know Flash to do it. We (I) will > get > > > out of > > > > your way and help in certain places like making sure the compiler > > is > > > > correctly transpiling. > > > > > > > > In case you are wondering why I think Flash is a ton of work to > > > emulate, > > > > here's why: If you only used Flex APIs (and did not use > > > "lower-level" > > > > Flash APIs), then there is no promise of frame-rates. In Flex, > you > > > > instantiated a UI widget, added it to the DOM, and it showed up > > > > eventually. That is effectively all Flex promised. I am very > > > certain I > > > > can do that in a browser or even in native code on mobile > devices. > > > And > > > > even if there was 1 million Flex apps out there, I'll be > overjoyed > > > if we > > > > end up helping 1000 apps get ported over the next few years. So > we > > > only > > > > need to emulate enough of Flex and Flash for a 1000 different > ways > > > that > > > > Flex APIs (and some Flash APIs) were used. > > > > > > > > But for those of you willing to take on emulating Flash, there > were > > > > probably a billion Flash SWFs out there using Flash APIs in > > millions > > > of > > > > different ways, some of which rely on frame-rates and other > timing > > > related > > > > aspects like the deferred rendering model. Given that a browser > > > often > > > > updates more immediately, Flash emulation might run into issues > > > where the > > > > screen updates before desired. Fixing these things will be very > > > hard. And > > > > then to do it all over again on the next popular > runtime/platform? > > > That's > > > > too much work for me, but I wish you well on your journey. > > > > > > > > In short, Flex has a much simpler set of expectations than Flash, > > and > > > > Royale is even simpler, making it easier to support different > > > > outputs/platforms/runtimes in the future. We are not promising > > that > > > the MX > > > > emulation will run on other outputs/platforms/runtimes. We will > > try > > > to > > > > make sure Basic and probably Express and Jewel run on other > > > > outputs/platforms/runtimes. Why is that? Because MX emulation > > will > > > > probably emulate an ENTER_FRAME event and it may not be worth > > > carrying that > > > > forward forever. The MX emulation is mainly designed to save > time > > > getting > > > > off of Flash and buy you time to develop the next generation of > > your > > > > application in Basic or Jewel, resulting in small, faster code, > or > > a > > > more > > > > modern UI, but in both cases, better future-proofing for the next > > hot > > > > output/platform/runtime. > > > > > > > > If you are still reading, one more point: Sometimes, it is time > > for > > > a > > > > paradigm shift. Back when the automobile was invented, someone > > came > > > out > > > > with a mechanical horse, figuring that everyone knew how to use > > > reins and > > > > would not want to learn how to use a steering wheel. But it > turned > > > out > > > > that the automobile, despite the weird usability of the steering > > > wheel, > > > > became the dominant trend. People are proposing ways to do > > > animation on > > > > the web that is different from Flash and those ways may be more > > > portable to > > > > other platforms/runtimes. So instead of coding the mechanical > > > horse, it > > > > may be time to move people to something longer lasting. That's > why > > > Basic in > > > > Royale is all about strands and beads and PAYG, a completely new > > > paradigm > > > > from Flex's one-component-set paradigm. That was done on > purpose, > > > to make > > > > it easier for volunteers to contribute beads with less concern > > about > > > > impacting big complex components, so that we can migrate to other > > > platforms > > > > by not having APIs that are too platform specific, etc. > > > > > > > > My 2 cents, > > > > -Alex > > > > > > > > On 10/22/19, 10:24 AM, "[email protected]" < > > > > [email protected]> wrote: > > > > > > > > Hi Carlos, > > > > I’m just very confused with platform specified Apis you > > > mentioned. I > > > > think flash API is the base of everything, including flex. So we > > > make flash > > > > API run everywhere, then all other projects/libs would run > > > everywhere too, > > > > including flex. For our users they use exact same codes and > target > > to > > > > multiple platforms, that is exact what “code once, run > everywhere” > > > means, > > > > isn’t it? > > > > > > > > For different environments/platforms we just have to modify > > some > > > of > > > > implementations while remaining the API (function signature, > class, > > > > namespace) to be consistent. > > > > > > > > Wasm runs in a sandbox of browsers, that means all run-time > > > > environments are provided by browsers, it has the same > environment > > > as JS > > > > dose. So for wasm, we still need to access DOM as usual, nothing > > > special > > > > than JS. Thus, what JS could do, wasm may do so. What JS can’t > do, > > > wasm may > > > > not either. > > > > > > > > Cheers > > > > Jason > > > > > > > > > 在 2019年10月23日，上午12:01，Carlos Rovira < > [email protected] > > > > > > 写道： > > > > > > > > > > Hi Kenny, > > > > > > > > > > For each platform there's ultimately a concrete API. So > > Royale > > > ends > > > > > translating to the real APIs. Users writes in Royale > ensuring > > > their > > > > codes > > > > > are reliable over time no matter what platform you use or > is > > > > trending. > > > > > > > > > > I'd want to write a form, a game or a whatever we want with > > > Royale > > > > code and > > > > > let compiler know how to output the best and optimized > > > platform code > > > > we can. > > > > > > > > > > So Add WASM? we're all share that goal without doubt. > > > > > About APIs I think is important we understand the multi > > target > > > > nature in > > > > > Royale. > > > > > > > > > > I think the problem would be trying to bring the same Flash > > > API, and > > > > make > > > > > users code using that APIs, since that defeats the purpose > of > > > Royale. > > > > > > > > > > Maybe other option would be the same we're doing with > > emulation > > > > components. > > > > > While Royale brings new APIs and new Code and concepts like > > > PAYG, > > > > > Strands/Beads,... > > > > > We have MXRoyale to emulate Flex under the new code base > that > > > > incorporates > > > > > all the goodness of Royale, so people can compile a Flex > > > project in > > > > Royale. > > > > > > > > > > So doing adding WASM to Royale in the current APIs, could > > allow > > > > create an > > > > > emulation library (lets say instead MXRoyale, call it > > > FlashRoyale) > > > > that > > > > > will emulate Flash API in order to allow Flash projects > > > compile with > > > > Royale > > > > > compiler and output to WASM, JS, or SWF. > > > > > > > > > > Sound this like a real option? > > > > > > > > > > Carlos > > > > > > > > > > > > > > >> El mar., 22 oct. 2019 a las 17:01, Kenny Lerma (< > > > > [email protected]>) > > > > >> escribió: > > > > >> > > > > >> I didn't realize that Royale was actually converting > > > > >> "org.apache.royale.events.Event" to "flash.events.Event" > for > > > the SWF > > > > >> target. It's the idea of one language for multiple > targets. > > > > However, this > > > > >> seems strange in that we are using ActionScript to begin > > > with, but > > > > ditching > > > > >> the naming convention. Is this because of legal reasons > or > > a > > > need > > > > to > > > > >> separate Royale from Flash all together? I would imagine > > > both. > > > > While I > > > > >> greatly appreciate the efforts on the Flex side of > things, I > > > > believe both > > > > >> Jason and I are looking for the best route to fill the > void > > > of a > > > > graphics > > > > >> rendering engine and/or the ability to bring in existing > > flash > > > > projects, > > > > >> but compile to JavaScript. Additionally, WASM gives us > the > > > > performance we > > > > >> need for these kinds of high animation projects. The path > is > > > a bit > > > > blurry > > > > >> to integrating this with Royale. > > > > >> > > > > >> Ultimately, I think we need to add WASM to the compiler > and > > > build a > > > > Flash > > > > >> API separate from Royale, but maybe there is a better > route. > > > > >> > > > > >> Kenny > > > > >> > > > > >> On Tue, Oct 22, 2019 at 6:59 AM Carlos Rovira < > > > > [email protected]> > > > > >> wrote: > > > > >> > > > > >>> Hi Jason, > > > > >>> > > > > >>> The scope of Flash was more wide and open than Flex. Flex > > was > > > > created to > > > > >>> target Applications. Most of the time business > applications > > > > composed by > > > > >>> forms, data grids, lists, graphs and other visual data > > > > representations. > > > > >>> While Flash can do that, productivity was very low in > real > > > world > > > > use > > > > >> cases. > > > > >>> So Flex was the perfect solution to get great visuals and > > > > renderings of > > > > >>> that kind of business applications and get a productivity > > > > unmatched by > > > > >>> other solutions. > > > > >>> > > > > >>> Since Royale was created from Flex concepts it tries to > > > solve the > > > > same > > > > >>> scope as Flex, but as we was able to use Flash pieces > > inside > > > Flex > > > > and mix > > > > >>> both, Royale don't want to "cut its own hands" and put a > > > fence. I > > > > think > > > > >> we > > > > >>> all want Royale to expand limits and go beyond Flex > limits. > > > > >>> > > > > >>> About APIs. If I understand correctly, others already go > > the > > > route > > > > to > > > > >> have > > > > >>> "flash.*" APIs to make old Flash SWFs run in JS or WASM. > > > > >>> > > > > >>> IMHO, Royale should have its own API. For example if we > > > choose the > > > > Event > > > > >>> example in Roayle we have: > > > > >>> > > > > >>> org.apache.royale.events.Event > > > > >>> > > > > >>> and that makes Royale users be able to compile for SWF > > (that > > > will > > > > in the > > > > >>> end use "flash.events.Event" > > > > >>> > > > > >>> COMPILE::SWF > > > > >>> public class Event extends flash.events.Event > implements > > > > IRoyaleEvent > > > > >>> > > > > >>> and for JS will use Google Closure event. > > > > >>> > > > > >>> COMPILE::JS > > > > >>> public class Event extends goog.events.Event > implements > > > > IRoyaleEvent > > > > >> { > > > > >>> > > > > >>> If you work in WASM, the org.apache.royale.events.Event, > > > should > > > > expand > > > > >> that > > > > >>> class to what WASM specs will impose in the final > > > implementation > > > > (don't > > > > >>> know right now what's or maybe this could be a silly > > example > > > and > > > > events > > > > >> be > > > > >>> managed by JS) > > > > >>> > > > > >>> So in resume. Working in WASM, would mean as well in > > working > > > in > > > > some > > > > >>> "display" ARQ that would introduce a whole way of drawing > > and > > > > animating > > > > >> in > > > > >>> Royale that not exists right now and that means write > > > compiler, > > > > write > > > > >>> classes that support SWF, JS and WASM... and more > > > > >>> > > > > >>> I'm right in this way of thinking? or maybe I'm wrong? > > > > >>> > > > > >>> Thanks > > > > >>> > > > > >>> > > > > >>> El mar., 22 oct. 2019 a las 8:03, Alex Harui > > > > (<[email protected] > > > > >>> ) > > > > >>> escribió: > > > > >>> > > > > >>>> Hi Jason, > > > > >>>> > > > > >>>> Volunteers in this project are welcome to work on > whatever > > > they > > > > want. > > > > >>>> > > > > >>>> The reason I am interested in Flex instead of Flash is > > > because > > > > Flex was > > > > >>>> designed to abstract away the Flash API, so Flex is > going > > > to be > > > > more > > > > >>> easily > > > > >>>> portable to different runtimes than Flash. Supporting > > > Flash will > > > > be > > > > >> more > > > > >>>> work than I have time and interest for. I'm not sure we > > > have the > > > > >> number > > > > >>> of > > > > >>>> people to do it, or that they know Flash well enough to > do > > > it. > > > > Also, > > > > >>> last > > > > >>>> time we looked at Li Zhi's code, there were issues about > > the > > > > legality > > > > >> of > > > > >>>> the implementation. Apache probably can't accept > > > > reverse-engineered > > > > >>>> implementations. > > > > >>>> > > > > >>>> By focusing on Flex, we actually abstract away the > > rendering > > > > model. > > > > >> MXML > > > > >>>> does not dictate code flow. Flex does not promise a > > > deferred > > > > rendering > > > > >>>> model based on frames. We have emulated a fair amount > of > > > the > > > > >> networking > > > > >>>> and some of the IO, but I don't want to be obligated to > > > support > > > > all of > > > > >>> it. > > > > >>>> > > > > >>>> But that doesn't mean you shouldn't try. The Flash > > > implementation > > > > >> might > > > > >>>> be better off in a different repo outside of Apache > unless > > > there > > > > you > > > > >> can > > > > >>>> get more volunteers to pitch in and clear away any > > > > >>>> legal/intellectual-property/licensing concerns. > > > > >>>> > > > > >>>> My 2 cents, > > > > >>>> -Alex > > > > >>>> > > > > >>>> On 10/21/19, 9:01 PM, "Jason Huang" < > > > [email protected]> > > > > wrote: > > > > >>>> > > > > >>>> Hi guys, > > > > >>>> > > > > >>>> Now I see, we have same goals for delivering a > > > comprehensive > > > > SDK > > > > >> to > > > > >>>> our > > > > >>>> users. > > > > >>>> > > > > >>>> As for Flash APIs, for my understanding, it is AS3 > > > language > > > > >> build-in > > > > >>>> basic > > > > >>>> library that provides basic Rendering, IO, > networking, > > > etc. > > > > >>>> The relationship of Flash APIs with AS3 is similar to > > > DOM with > > > > JS, > > > > >>> .Net > > > > >>>> with C#, stdlib with C++, etc. I did not actually > > > compare AS3 > > > > to > > > > >> TS, > > > > >>> I > > > > >>>> meant > > > > >>>> without flash api support, AS3 would be much worse > > > especially > > > > when > > > > >> it > > > > >>>> used > > > > >>>> for targeting web applications. > > > > >>>> To make Royale much more reliable, I suppose except > > high > > > level > > > > >> flash > > > > >>>> APIs, > > > > >>>> such as MovieClip( timeline based), etc, we should at > > > least > > > > >> consider > > > > >>>> basic > > > > >>>> IO, networking, rendering apis. > > > > >>>> > > > > >>>> As for other projects that tried to emulating flash > > apis, > > > > >>>> SpriteFlexJS is a project that my friend Li Zhi > > started > > > 4 > > > > years > > > > >> ago, > > > > >>>> our > > > > >>>> initial thought was testing the capabilities for > > FalconJX > > > > compiler, > > > > >>>> After this project, I started AJC project to > officially > > > > emulating > > > > >>> Flash > > > > >>>> APIs for commercial AS3 projects. During AJC > > > development, we > > > > made > > > > >> our > > > > >>>> own c++ version of Flash APIs( not finished all of > them > > > yet) > > > > to be > > > > >> as > > > > >>>> accurate as possible, almost 98% same result as > > original > > > flash > > > > >> player > > > > >>>> dose, > > > > >>>> regardless so many differences between DOM and flash > > > player. > > > > >>>> OpenFL made all flash API available, but inside it > went > > > > different > > > > >>>> approaching, graphics vector rendering, event flow, > > > networking > > > > are > > > > >>> all > > > > >>>> different than original flash player, thus made > > > > >>>> existing AS3 project impossible to use it without > > > seriously > > > > >> modifying > > > > >>>> source codes. > > > > >>>> Ruffle is another project that written in rust to > > emulate > > > > entire > > > > >>> flash > > > > >>>> player, here is its own roadmap > > > > >>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fruffle-rs%2Fruffle%2Fwiki%2FRoadmap&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=5igqZinLx69biOTP6tqyq4R17RXiey9K%2BFv%2Fobs9AkQ%3D&reserved=0 > > > > >>> , > > > > >>>> it is a totally different > > > > >>>> approaching that parsing SWF at runtime plugin(wasm)/ > > > desktop > > > > >> player > > > > >>>> other > > > > >>>> than > > > > >>>> compiling AS3 from the sources once again. When it > > > finished, it > > > > >> would > > > > >>>> be a > > > > >>>> good choice for exiting AS3 projects. > > > > >>>> > > > > >>>> I suggest we get our hands on basic flash API > > > implementations > > > > as > > > > >> soon > > > > >>>> as > > > > >>>> possible, how would you guys think? > > > > >>>> > > > > >>>> Cheers > > > > >>>> Jason > > > > >>>> > > > > >>>> > > > > >>>> On Mon, Oct 21, 2019 at 5:05 PM Carlos Rovira < > > > > >>> [email protected] > > > > >>>>> > > > > >>>> wrote: > > > > >>>> > > > > >>>>> Hi Jason, > > > > >>>>> > > > > >>>>> to continue complementing the understanding of our > goals. > > > Royale > > > > >>> has > > > > >>>> the > > > > >>>>> advantage to be prepared in theory to output to > multiple > > > targets > > > > >>>> (SWF, JS, > > > > >>>>> WASM, ...native iOS?, native Android?,....). Since > Royale > > > is an > > > > >> SDK > > > > >>>> it > > > > >>>>> provides all the user need to build an app (compiler, > > > framework, > > > > >> UI > > > > >>>> set, > > > > >>>>> communications, reflection, XML,....). > > > > >>>>> > > > > >>>>> I think great power of your contribution is to make > users > > > that > > > > >> was > > > > >>>>> outputting JS or SWF be able to output WASM without > > > changing > > > > >> their > > > > >>>> user's > > > > >>>>> code. > > > > >>>>> > > > > >>>>> That's for me the main point of Royale for years to > come, > > > to make > > > > >>>> users > > > > >>>>> agnostic of technology trends. Royale will handle this > > for > > > them, > > > > >>>> adding the > > > > >>>>> support so they don't need to change a single line of > > code > > > in > > > > >> their > > > > >>>> apps. > > > > >>>>> > > > > >>>>> For example, imagine actual teams working with React to > > > make a > > > > >> new > > > > >>>> app. > > > > >>>>> That app has potential to grow as Flex apps did in the > > > past. And > > > > >> be > > > > >>>> very > > > > >>>>> big codebase. Then in few years, WASM should be the new > > > trend and > > > > >>>> making > > > > >>>>> people migrate from JS to WASM. Maybe by that time > React > > > could > > > > >>>> handle WASM > > > > >>>>> output correctly or not, but due to fragmentation in > > > libraries > > > > >> and > > > > >>>> code, I > > > > >>>>> think that should not be an easy task. Royale instead > > > since has > > > > >> the > > > > >>>> multi > > > > >>>>> target at its Core should be able to reach that goal > > > better and > > > > >>>> faster with > > > > >>>>> people like you. > > > > >>>>> > > > > >>>>> About Flash API. If we use our own royale based API > that > > > can > > > > >> output > > > > >>>> to the > > > > >>>>> platform we want (instead of flash.*, think about in > > > royale.*), I > > > > >>>> think > > > > >>>>> this has more power that bringing the older Flash API, > > > since > > > > >> you're > > > > >>>> writing > > > > >>>>> for a platform that is open and prepared for the > future. > > > As Alex > > > > >>>> said, > > > > >>>>> there's others already allowing flash APIs and using > > Royale > > > > >>>> compiler, so if > > > > >>>>> that's really what you want, you can plan to work > between > > > royale > > > > >>> and > > > > >>>> those > > > > >>>>> projects. I think those are OpenFL and SpriteFlexJS. > > > > >>>>> > > > > >>>>> I think if you work in Royale for WASM, you can plan to > > > make it > > > > >>>> happen for > > > > >>>>> Royale itself and for other projects depending on it... > > so > > > more > > > > >>>> users will > > > > >>>>> be interested in that new power feature and will make > > > Royale even > > > > >>>> more > > > > >>>>> interesting and appealing for companies and individuals > > > looking > > > > >> to > > > > >>>> what > > > > >>>>> tech for the future they should use. > > > > >>>>> > > > > >>>>> Maybe is important in this point to see if this new > point > > > of view > > > > >>>> can be > > > > >>>>> interesting to you or maybe that's not the way to > > envision > > > the > > > > >>>>> possibilities for all this stuff. > > > > >>>>> > > > > >>>>> Thanks! > > > > >>>>> > > > > >>>>> Carlos > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> El lun., 21 oct. 2019 a las 8:31, Alex Harui > > > > >>>> (<[email protected]>) > > > > >>>>> escribió: > > > > >>>>> > > > > >>>>>> Royale is currently primarily focused on migrating > Flex > > > apps, > > > > >>>> which is a > > > > >>>>>> subset of all Flash apps. There are a couple of other > > > > >> non-Apache > > > > >>>>> projects > > > > >>>>>> looking at emulating the Flash APIs. So if your app > is > > > pure > > > > >>>> Flash, you > > > > >>>>>> might want to contact those other projects. The main > > > > >> restriction > > > > >>>> is > > > > >>>>> pretty > > > > >>>>>> much number of people on the project. We're busy > enough > > > with > > > > >>> Flex > > > > >>>> apps > > > > >>>>> and > > > > >>>>>> not worrying about timelines and other Flash things. > > > > >>>>>> > > > > >>>>>> We are not really competing with TS. We use AS3 and > > MXML > > > > >>> because > > > > >>>> that's > > > > >>>>>> what the compiler can parse. We output SWF and JS > > because > > > > >> that's > > > > >>>> what > > > > >>>>> our > > > > >>>>>> compiler can output. It should be possible to allow > TS > > in > > > > >> Royale > > > > >>>> apps if > > > > >>>>>> that what volunteers want to add to the compiler. We > > > would > > > > >>> gladly > > > > >>>> accept > > > > >>>>>> your contribution towards WASM output from the > compiler. > > > > >>>>>> > > > > >>>>>> Hopefully all of these efforts can coexist. I think > the > > > other > > > > >>>> Flash > > > > >>>>>> emulation projects are using the Royale compiler. > > Royale > > > can > > > > >> the > > > > >>>> home of > > > > >>>>>> the compiler used by many projects. > > > > >>>>>> > > > > >>>>>> My 2 cents, > > > > >>>>>> -Alex > > > > >>>>>> > > > > >>>>>> On 10/20/19, 6:51 PM, "Jason Huang" < > > > [email protected]> > > > > >>>> wrote: > > > > >>>>>> > > > > >>>>>> Hi, > > > > >>>>>> I understood what you concerned about > > > > >> licensing/copyrights. I > > > > >>>> won't > > > > >>>>>> use the > > > > >>>>>> previous AJC approaching at all, but writing a new > > > compiler > > > > >>>> that > > > > >>>>>> compiles > > > > >>>>>> AS3 codes to wasm format instead. So that would be > a > > > > >> totally > > > > >>>>> different > > > > >>>>>> approach than I used to do. > > > > >>>>>> > > > > >>>>>> As Alex mentioned "Royale currently has no > intention > > of > > > > >>>>>> duplicating/emulation the Flash API. We want new > > > Royale > > > > >> apps > > > > >>>> to be > > > > >>>>>> built > > > > >>>>>> on top of components instead of timelines and > > > > >>> DisplayObjects". > > > > >>>> For my > > > > >>>>>> understanding, we are just using AS3 as a typed > > > > >>>>>> language for building applications, nothing to do > > with > > > > >>> porting > > > > >>>>> various > > > > >>>>>> AS3 > > > > >>>>>> projects. Let's say if a AS3 project is purely > > > developed > > > > >>> based > > > > >>>> on > > > > >>>>> Flash > > > > >>>>>> API, in this case if it is willing to use Royale, > so > > > it has > > > > >>> to > > > > >>>> be > > > > >>>>>> re-written to adjust new APIs provided by Royale, > is > > > that > > > > >>>> correct? > > > > >>>>>> > > > > >>>>>> if our goal is providing a brand new tool chain and > > > apis > > > > >>> other > > > > >>>> than > > > > >>>>>> helping > > > > >>>>>> existing AS3 projects, I don't see a lot of > > > advantages for > > > > >>>> using AS3 > > > > >>>>>> over > > > > >>>>>> Type Script. Type Script has much more users than > AS3 > > > dose > > > > >>>> today, > > > > >>>>> plus > > > > >>>>>> Type > > > > >>>>>> Script has its own compiler to wasm already, known > as > > > > >>> Assembly > > > > >>>> Script > > > > >>>>>> compiler ( > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAssemblyScript%2Fassemblyscript&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=ZrzpkCx9Z3L9BXgNUnRPdHU6QBjNImtrutKqeP0F8qs%3D&reserved=0 > > > > >>>>>> ). > > > > >>>>>> > > > > >>>>>> I really wanna put all my efforts in to Royale to > > make > > > AS3 > > > > >> to > > > > >>>> shine > > > > >>>>> as > > > > >>>>>> other web based languages do, I really wanna know > > your > > > > >>> future > > > > >>>>>> plans/goals/ > > > > >>>>>> road map, and to find what exactly should I do with > > it. > > > > >>>>>> > > > > >>>>>> Cheers > > > > >>>>>> Jason Huang > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> On Mon, Oct 21, 2019 at 6:21 AM Alex Harui > > > > >>>> <[email protected] > > > > >>>>>> > > > > >>>>>> wrote: > > > > >>>>>> > > > > >>>>>>> Hi Jason, > > > > >>>>>>> > > > > >>>>>>> Welcome. I hope we find a way to work well with you. > > > > >>>>>>> > > > > >>>>>>> First, a slight correction to what Carlos said about > > > > >>>> copyrights. > > > > >>>>>> Just > > > > >>>>>>> about everything of significance is copyrighted by a > > > > >>> company > > > > >>>> or > > > > >>>>>> individual, > > > > >>>>>>> so we're not looking for things "not under a > > copyright".. > > > > >>>> But > > > > >>>>> there > > > > >>>>>> must > > > > >>>>>>> be an Apache-compatible license to use that > copyrighted > > > > >>>> material. > > > > >>>>>>> > > > > >>>>>>> Second, Royale currently has no intention of > > > > >>>> duplicating/emulation > > > > >>>>>> the > > > > >>>>>>> Flash API. IMO, the goal of Royale isn't to > propagate > > > > >>> Flash > > > > >>>> to > > > > >>>>> other > > > > >>>>>>> platforms, but to create some APIs that can migrate > to > > > > >>> other > > > > >>>>>> platforms, to > > > > >>>>>>> better future-proof new Royale applications. We've > > > > >>> emulated > > > > >>>> a few > > > > >>>>>> Flash > > > > >>>>>>> APIs to help those migrating Flex projects, but we > > don't > > > > >>>> have a > > > > >>>>> goal > > > > >>>>>> to > > > > >>>>>>> emulate all of them. We want new Royale apps to be > > built > > > > >>> on > > > > >>>> top of > > > > >>>>>>> components instead of timelines and DisplayObjects. > > > > >>>>>>> > > > > >>>>>>> HTH, > > > > >>>>>>> -Alex > > > > >>>>>>> > > > > >>>>>>> On 10/20/19, 9:06 AM, "Carlos Rovira" < > > > > >>>> [email protected]> > > > > >>>>>> wrote: > > > > >>>>>>> > > > > >>>>>>> Hi Jason, > > > > >>>>>>> > > > > >>>>>>> great to have you in the list proposing that > plans. > > > > >>> Since > > > > >>>>> Royale > > > > >>>>>> is > > > > >>>>>>> multi > > > > >>>>>>> target with current support for SWF and JS, we > > really > > > > >>>> want to > > > > >>>>>> have > > > > >>>>>>> others > > > > >>>>>>> and users asked many times about WASM support. So > > > > >> WASM > > > > >>>> is maybe > > > > >>>>>> the > > > > >>>>>>> most > > > > >>>>>>> requested and wanted new target in Royale. So, > yes, > > > > >> we > > > > >>>> want > > > > >>>>>>> contributors > > > > >>>>>>> that work in WASM target :). > > > > >>>>>>> > > > > >>>>>>> Hope others in the project can give some words > here > > > > >> and > > > > >>>> give > > > > >>>>> his > > > > >>>>>>> opinion. > > > > >>>>>>> In the meantime I think the most important thing > is > > > > >> to > > > > >>>>>> understand as > > > > >>>>>>> best > > > > >>>>>>> as possible for you how Apache projects work and > > that > > > > >>> is > > > > >>>> very > > > > >>>>>>> different to > > > > >>>>>>> closed source and things driven by companies. It's > > > > >>>> important > > > > >>>>> that > > > > >>>>>>> anything > > > > >>>>>>> you want to contribute is not under any copyright > > and > > > > >>> is > > > > >>>> new > > > > >>>>>> code you > > > > >>>>>>> contribute to the project. Apache is all about > open > > > > >>>> source, so > > > > >>>>>> is very > > > > >>>>>>> important that no company or individual owns the > > code > > > > >>>> and be > > > > >>>>>> always > > > > >>>>>>> available to the public and people can use under > > > > >> Apache > > > > >>>> License > > > > >>>>>> v2.0 > > > > >>>>>>> rules. > > > > >>>>>>> I think you should check all you can about how > > Apache > > > > >>>> works > > > > >>>>> [1]. > > > > >>>>>>> Anything > > > > >>>>>>> you need to ask please do here. > > > > >>>>>>> > > > > >>>>>>> The next thing important to this concrete project, > > > > >>> Apache > > > > >>>>>> Royale, is to > > > > >>>>>>> understand we're a community were we respect the > > work > > > > >>> of > > > > >>>> others > > > > >>>>>> in the > > > > >>>>>>> community, and we expect the same from new members > > > > >> and > > > > >>>>>> contributors. So > > > > >>>>>>> although code and skills is important, fellowship, > > > > >>>> respect and > > > > >>>>>> other > > > > >>>>>>> social > > > > >>>>>>> things are very important to us. > > > > >>>>>>> > > > > >>>>>>> The way new contributors start working is through > > > > >> Pull > > > > >>>> Request > > > > >>>>> in > > > > >>>>>>> GitHub > > > > >>>>>>> (PRs), interacting in this list (and/or in the > users > > > > >>>> list if > > > > >>>>> you > > > > >>>>>> want) > > > > >>>>>>> and > > > > >>>>>>> doing as you consider to help the project going > > on.As > > > > >>>> well, > > > > >>>>> this > > > > >>>>>> is all > > > > >>>>>>> done freely as you consider and nobody can request > > > > >>>> anything to > > > > >>>>>> you > > > > >>>>>>> since is > > > > >>>>>>> something we all do because we want. > > > > >>>>>>> > > > > >>>>>>> I think to start is important that you try to > expose > > > > >> in > > > > >>>> this > > > > >>>>>> list how > > > > >>>>>>> you > > > > >>>>>>> plan to implement WASM support in Royale so the > rest > > > > >> of > > > > >>>> the > > > > >>>>> team > > > > >>>>>> can > > > > >>>>>>> guide > > > > >>>>>>> you and discuss things for two reason. a) Guide > you > > > > >> to > > > > >>>>> integrate > > > > >>>>>> in the > > > > >>>>>>> best possible way, since you can have in mind some > > > > >> path > > > > >>>> and > > > > >>>>> that > > > > >>>>>> could > > > > >>>>>>> be > > > > >>>>>>> not doable for different reasons: technical, wrong > > > > >>> specs > > > > >>>> that > > > > >>>>>> defeats > > > > >>>>>>> some > > > > >>>>>>> important Royale principles, or any other things, > b) > > > > >>>> save you > > > > >>>>>> time. We > > > > >>>>>>> don't want you to spend lots of time, and reach a > > > > >> point > > > > >>>> of > > > > >>>>>> merge, and > > > > >>>>>>> then > > > > >>>>>>> others in the team say you is not possible to > > > > >> integrate > > > > >>>> for > > > > >>>>> some > > > > >>>>>>> reason of > > > > >>>>>>> design or compatibility with the global direction > of > > > > >>> the > > > > >>>>> project. > > > > >>>>>>> So in resume, please try to write and explain here > > > > >>> before > > > > >>>>>> starting any > > > > >>>>>>> effort to avoid lose time. This will be by far > more > > > > >>>> efficient > > > > >>>>>> and will > > > > >>>>>>> save > > > > >>>>>>> you from any frustration in the future. > > > > >>>>>>> > > > > >>>>>>> Other point is that we expect that you can accept > > > > >>>> critics as > > > > >>>>>> part of > > > > >>>>>>> the > > > > >>>>>>> team work and this is important. Something that > can > > > > >>>> happen is > > > > >>>>>> that > > > > >>>>>>> what you > > > > >>>>>>> could have in mind something that can't be done > for > > > > >> any > > > > >>>> reason > > > > >>>>>> and it > > > > >>>>>>> may > > > > >>>>>>> be difficult to accept the design of the > community. > > > > >> But > > > > >>>> in > > > > >>>>>> Apache all > > > > >>>>>>> things have to happen by consensus. That's the > > > > >> "Apache > > > > >>>> way". > > > > >>>>>>> > > > > >>>>>>> Said all this, I really hope you find your way in > > our > > > > >>>> community > > > > >>>>>> and > > > > >>>>>>> could > > > > >>>>>>> be the guy that make WASM be a reality in Royale. > I > > > > >>> know > > > > >>>> the > > > > >>>>>> effort is > > > > >>>>>>> not > > > > >>>>>>> easy at all, maybe is a long run. I really think > > that > > > > >>> if > > > > >>>> you > > > > >>>>>> bring > > > > >>>>>>> something that could make Apache Royale be the > next > > > > >>>> front end > > > > >>>>>>> technology > > > > >>>>>>> that get to be massively used since the current > ones > > > > >>>> (like > > > > >>>>> React, > > > > >>>>>>> Angular > > > > >>>>>>> or Vue), will never have this kind of power > feature. > > > > >> If > > > > >>>> you get > > > > >>>>>> it, I > > > > >>>>>>> really would like to add WASM support to Jewel UI > > set > > > > >>> for > > > > >>>>>> example. > > > > >>>>>>> > > > > >>>>>>> So, definitely, expecting to work with you and > help > > > > >> you > > > > >>>> to make > > > > >>>>>> this > > > > >>>>>>> happen > > > > >>>>>>> :) > > > > >>>>>>> > > > > >>>>>>> Best > > > > >>>>>>> > > > > >>>>>>> Carlos > > > > >>>>>>> > > > > >>>>>>> [1] > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=M4STHy0aowuks6gPH97mgG7NL%2FdZrgO2YTpSAnhurW0%3D&reserved=0 > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> El dom., 20 oct. 2019 a las 6:30, Jason Huang (< > > > > >>>>>>> [email protected]>) > > > > >>>>>>> escribió: > > > > >>>>>>> > > > > >>>>>>>> Hi, everyone, > > > > >>>>>>>> > > > > >>>>>>>> I'm Jason Huang, I really like to work with you > > > > >> guys > > > > >>> to > > > > >>>>>> improve and > > > > >>>>>>> add new > > > > >>>>>>>> features to Apache Royale. > > > > >>>>>>>> > > > > >>>>>>>> In early 2017, I started a project that compiling > > > > >> AS3 > > > > >>>> to JS > > > > >>>>> and > > > > >>>>>>> interacting > > > > >>>>>>>> with a WASM version of basic C++ re-written flash > > > > >>>> runtime > > > > >>>>>> apis. The > > > > >>>>>>> project > > > > >>>>>>>> known as AJC. The initial idea of this project is > > > > >> to > > > > >>>> help > > > > >>>>>> existing > > > > >>>>>>> AS3 > > > > >>>>>>>> projects to be able to run on the web without flash > > > > >>>> player > > > > >>>>>> plugin. > > > > >>>>>>> In the > > > > >>>>>>>> end of 2017, the project finally has its own SDK ( > > > > >>>> customized > > > > >>>>>> Falcon > > > > >>>>>>> JX > > > > >>>>>>>> compiler, and customized emscripten sdk), a stable > > > > >>>> customized > > > > >>>>>> flash > > > > >>>>>>> develop > > > > >>>>>>>> IDE that has same experiences ( building, > > > > >>>> debugging,etc) as > > > > >>>>>> original > > > > >>>>>>> one > > > > >>>>>>>> that manage original as3 projects. Finally, the > > > > >> only > > > > >>>> thing > > > > >>>>>> that left > > > > >>>>>>> to do > > > > >>>>>>>> is finishing the whole Flash API using c++ that may > > > > >>>> run with > > > > >>>>>> the both > > > > >>>>>>>> environment that browser provided and native > > > > >>> platforms > > > > >>>> such > > > > >>>>> as > > > > >>>>>>> Windows, > > > > >>>>>>>> Mac, Linux. In the middle of 2018, I finished most > > > > >> of > > > > >>>> crucial > > > > >>>>>> apis of > > > > >>>>>>>> flash, such as the whole packages of > > > > >>>> flash.display(hardware > > > > >>>>>>> accelerated > > > > >>>>>>>> rendering), flash.display3D, flash.events, > > > > >> flash.net > > > > >>> , > > > > >>>>>> etc,.and it > > > > >>>>>>> was able > > > > >>>>>>>> to meet all apis requirements from a commercial AS3 > > > > >>> ui > > > > >>>> lib > > > > >>>>>> known as > > > > >>>>>>> flex > > > > >>>>>>>> lite( > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fflexlite&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=DH2TQ4SW4wt57tfFulMFdGm6VJK0B2Rro9yWn78QTxg%3D&reserved=0 > > > > >>>>>> ), > > > > >>>>>>> I successfully built all examples from > > > > >>>>>>>> that lib to js and communicating with my wasm > > > > >> version > > > > >>>> of > > > > >>>>> flash > > > > >>>>>> apis. > > > > >>>>>>>> Unfortunately, after that bad things happened to > > > > >> me, > > > > >>> I > > > > >>>> had to > > > > >>>>>> leave. > > > > >>>>>>> Thus > > > > >>>>>>>> AJC project has been suspended in the middle of > > > > >>> 2018. > > > > >>>> The > > > > >>>>> only > > > > >>>>>>> thing left > > > > >>>>>>>> to the public is a fork repo from my original one ( > > > > >>>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshanewfx%2FAJC-Flash-WebAssembly-Examples&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=KSyR0u9AsPJA7xyzkAFD%2BCVYtNgfj3fdXRVKcIXS3Jk%3D&reserved=0 > > > > >>>>>>> ). > > > > >>>>>>>> > > > > >>>>>>>> After 17 months, today, I am able to continue this > > > > >>>> project > > > > >>>>> once > > > > >>>>>>> again. But > > > > >>>>>>>> this time I decided to bring it to the public > > > > >>>> entirely. And > > > > >>>>>> working > > > > >>>>>>> with > > > > >>>>>>>> you guys should be more efficient and reliable. > > > > >> After > > > > >>>> all the > > > > >>>>>> things > > > > >>>>>>> I have > > > > >>>>>>>> been doing with AJC, now I have a plan that compile > > > > >>>> AS3 to > > > > >>>>> wasm > > > > >>>>>>> directly, > > > > >>>>>>>> without w/r memories through embind api that much. > > > > >> As > > > > >>>>>> previously all > > > > >>>>>>> as3 > > > > >>>>>>>> code being compiled to js first, then those js > > > > >>> calling > > > > >>>> every > > > > >>>>>> single > > > > >>>>>>> flash > > > > >>>>>>>> api functions in wasm through memory reading and > > > > >>>> writing, > > > > >>>>> this > > > > >>>>>> is > > > > >>>>>>> very > > > > >>>>>>>> consuming at runtime. > > > > >>>>>>>> > > > > >>>>>>>> I have few brief questions: > > > > >>>>>>>> How you guys think about my plan? > > > > >>>>>>>> What is the state of Royale? is it similar with > > > > >>>> previous > > > > >>>>>> falcon jx > > > > >>>>>>> with > > > > >>>>>>>> more tooling and frameworks added? > > > > >>>>>>>> Did you guys implement a js version of flash apis? > > > > >>>>>>>> > > > > >>>>>>>> Cheers > > > > >>>>>>>> Jason Huang > > > > >>>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> -- > > > > >>>>>>> Carlos Rovira > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683143050&sdata=sM%2BDcXvGE%2FZw1acAHTpcXNviJMZQ2MmvaGOsmhfsxiA%3D&reserved=0 > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> -- > > > > >>>>> Carlos Rovira > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683153042&sdata=%2F8cXxwpmHOsmNG0BIb3valYdZf%2BReOV5KwiJ%2FL1AirM%3D&reserved=0 > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> -- > > > > >>> Carlos Rovira > > > > >>> > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683153042&sdata=%2F8cXxwpmHOsmNG0BIb3valYdZf%2BReOV5KwiJ%2FL1AirM%3D&reserved=0 > > > > >>> > > > > >> > > > > > > > > > > > > > > > -- > > > > > Carlos Rovira > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C15286735ed6241eae28e08d7573b567d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637073784683153042&sdata=%2F8cXxwpmHOsmNG0BIb3valYdZf%2BReOV5KwiJ%2FL1AirM%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
