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 >
