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, "jasonhuang1...@gmail.com" <jasonhuang1...@gmail.com>
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 <carlosrov...@apache.org> 写道：
>
> 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 (<ke...@kennylerma.com>)
>> 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 <carlosrov...@apache.org>
>> 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 (<aha...@adobe.com.invalid
>>> )
>>> 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" <jasonhuang1...@gmail.com> 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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416867258&sdata=cKIyl9Dc3%2FPGKDPgKXoX7OIwNLFSGrr0jjp%2FU9pBJEM%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 <
>>> carlosrov...@apache.org
>>>>>
>>>> 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
>>>> (<aha...@adobe.com.invalid>)
>>>>> 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" <jasonhuang1...@gmail.com>
>>>> 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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=Dh%2F5%2Bz5WKGK2Z8y7ogvynke228wgNR5ZHvxv5NNYz1A%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
>>>> <aha...@adobe.com.invalid
>>>>>>
>>>>>> 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" <
>>>> carlosrov...@apache.org>
>>>>>> 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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=ChwMTAKkf%2BwSGEXxJkYnIWNuhWkjsSlppu2%2BJ88wcuU%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El dom., 20 oct. 2019 a las 6:30, Jason Huang (<
>>>>>>> jasonhuang1...@gmail.com>)
>>>>>>> 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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=n1OBimdNgudwSXdkx%2F3G49gC9mZiJ2ctkIaWWh9W0%2Fg%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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=DokFZWwM1QP6jxjjJm7dc11E1doOOOsbn8RwuufIUio%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%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=d%2FSxEcSCFwuEDX5sv2XXQC0YlWivS9RfK9F0SOFoUzk%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>
>>>
>>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=d%2FSxEcSCFwuEDX5sv2XXQC0YlWivS9RfK9F0SOFoUzk%3D&reserved=0
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Carlos Rovira
>>>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416877251&sdata=d%2FSxEcSCFwuEDX5sv2XXQC0YlWivS9RfK9F0SOFoUzk%3D&reserved=0
>>>
>>
>
>
> --
> Carlos Rovira
>
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe31954d7a894f2e9de608d75714a065%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637073618416887244&sdata=2knoFSikeJ2JMdleziAVGfLQdIxndoMqwi%2Bveia4ORQ%3D&reserved=0
