What about simply naming the compiler "FlexJS Compiler"? Currently the maven plugin for example has a reference to falcon.jx and falcon and selects the right compc version using the Flex Tool Group API. So having different variants inside the compiler package doesn't seem too confusing.
Anyway the compiler should compile to Flash and compiler-jx can compile to flash and html5. From the scenarios you could use the compiler package: 1. Compile normal Flex applications to Flash 2. Compiler FlexJS to Flash and HTML5 using the FlexJS Framwork 3. Compiler FlexJS to HTML5 using external frameworks I think the use case 1 will be the one that's going to die out and the name FlexJS compiler for use case 2 and 3 sounds like a good match. Chris ________________________________________ Von: Josh Tynjala <joshtynj...@gmail.com> Gesendet: Samstag, 23. April 2016 03:02 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs FlexJS is a good name for the framework, and changing it will cause unnecessary confusion. At this point, most people are going to be primarily targeting JavaScript anyway. - Josh On Apr 22, 2016 4:55 PM, "jude" <flexcapaci...@gmail.com> wrote: > Flex JS conveys Flex as JavaScript framework but it's a hybrid really. > Could we reflect that Flex JS is a hybrid someway? > > Flex js is a sort of refactor. maybe: > > Flex Reactor > ReFlex > Flexo > Flex Nano > Flex Red > Flex Inc > Flexenstein > Flex Int > Flex passport > Flex Axiom > Flex Ion > Flex Action > > I don't know. > > There used to be a graph that showed how everything related to everything > else. But with Falcon, FlexJS, Falcon JX and so on it which have been added > after those graphs it can be confusing. Anyone want to draw something > updated under the new Apache Flex Platform? > > On Apr 21, 2016 9:41 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > > I think we’re all in agreement that FalconJX without the rest is an > important part even on its own. That’s what I meant by #1. > > > > I do think that naming is important. It helps “brand” a product. > Something like MXMLC2.0 is way too techie to be a “product”. > > > > I’ve been thinking of different ways to “brand” this, and I think I have > an idea which might work: > > > > Falcon and FalconJX and related toolchain which compiles AS and > optionally MXML into swc, swf and js could be branded as “FlexJS Core”. > > > > Everything else which is really about components and UI could be branded > as “FlexJS UI”. > > > > This is really similar to how JQuery did it with JQuery and JQuery UI. > > > > This would give a central brand, while preserving the concept that you > can use the compiler without the component sets (or even MXML at all). > > > > Harbs > > > > On Apr 20, 2016, at 8:02 AM, Alex Harui <aha...@adobe.com> wrote: > > > > > Good thoughts in this thread. > > > > > > My current thinking is this: > > > > > > FalconJX is a code name for the cross-compiler, but because there is an > > > Apache Falcon project, we need a better product name, and consider that > > > Falcon may someday compile SWFs for the Flex SDK. Adobe already used > > > ASC2.0, plus our version of Falcon handles MXML. We could use > MXMLC2.0, > > > but I'm not a huge fan of that. > > > > > > IMO, FlexJS has become a tool chain. It takes in MXML and AS and > outputs > > > SWFs or HTML/JS/CSS. We want to draw in every JS framework community > to > > > MXML-enable their components. Peter is hoping to finish a demo soon of > > > how much easier it is to learn and use CreateJS with MXML than with the > > > current CreateJS tutorials in JS. Maybe that will get the ball rolling > > > downhill. > > > > > > We will still build out a Basic component set for lowest-level > > > smallest-footprint apps. And we hope to build out MX and Spark-like > > > component sets to ease migration pain for existing Flex code bases. > > > > > > Yes, we have CreateJS, Jquery and GoogleMaps SWCs now, mostly as > > > proofs-of-concept. I hope to see the respective communities take over > > > development of these SWCs and expect them to do it outside of our > repos, > > > and have independent release schedules. > > > > > > So that's why I'm not sure a component set that targets Stage3D and > > > Starling has to be part of this community. It can certainly be a > customer > > > of the FlexJS tool chain, and we want it to be a customer, but we want > all > > > JS component set communities to be customers of FlexJS whether they > build > > > for SWF-first workflows or direct-to-JS workflows. > > > > > > Further down the road, once FlexJS grows to support distributed > > > development, we will be able to more clearly show the benefit of > SWF-first > > > workflows for those who need it. But that's for another thread > someday. > > > > > > My 2 cents, > > > -Alex > > > > > > On 4/19/16, 4:52 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > > > > >> I agree that FalconJX without the FlexJS framework is an important use > > >> case. That's basically why I'm here contributing to the project. I > want to > > >> champion the ActionScript language, and show how FalconJX will let you > use > > >> ActionScript anywhere that JavaScript is supported. That means (now or > > >> eventually) working with HTML, Node.js, Electron, and extensibility > APIs > > >> the like CEP panels that Harbs mentioned. > > >> > > >> For this use case, I think it's all about focusing on building a solid > > >> compiler. > > >> > > >> - Josh > > >> > > >> On Tue, Apr 19, 2016 at 4:04 PM, OmPrakash Muppirala > > >> <bigosma...@gmail.com> > > >> wrote: > > >> > > >>> We have an equally important component that is FalconJX. I envision > > >>> lot of > > >>> demand to work on non-FlexJS, pure FalconJX work. > > >>> > > >>> I think the Starling port falls under the category of pure FalconJX > work > > >>> and not FlexJS. We already have a game company working on making a > game > > >>> using the FalconJX compiler. > > >>> > > >>> Any thoughts on how we want to handle this use case? > > >>> > > >>> Thanks, > > >>> Om > > >>> > > >>> On Tue, Apr 19, 2016 at 3:44 PM, Harbs <harbs.li...@gmail.com> > wrote: > > >>> > > >>>> I missed a fifth item in my list of things we need: > > >>>> 5. We need tooling to pull in external swcs (externs and > > >>> cross-copiling > > >>>> ones) when compiling to Javascript. > > >>>> > > >>>> (I think we also need a naming convention for the two types of swcs. > > >>>> "definition swcs" and "code swcs”?) > > >>>> > > >>>> On Apr 20, 2016, at 1:37 AM, Harbs <harbs.li...@gmail.com> wrote: > > >>>> > > >>>>> Alex and Josh bring up good points. > > >>>>> > > >>>>> I’m thinking that I should step back and figure out what I was > > >>> trying > > >>> to > > >>>> accomplish by suggesting that we accept these APIs. > > >>>>> > > >>>>> In fact, I think it’s time we figure out exactly what FlexJS > > >>> actually > > >>> is. > > >>>>> > > >>>>> The motivation to accept the code into FlexJS was really to empower > > >>>> users to have access to great APIs and capabilities. However to say > > >>> that > > >>>> any cool functionality should become part of the core product > probably > > >>> does > > >>>> not make sense. Case in point: I’m currently working on FlexJS > support > > >>> for > > >>>> CEP panels in Adobe extensions. I think it’s great functionality, > but > > >>> I > > >>>> don’t believe it belongs in the Flex repo. > > >>>>> > > >>>>> To address the question of exactly what belongs in the FlexJS repo, > > >>> I > > >>>> think we need to address exactly what is the identity of FlexJS > > >>> actually > > >>>> is. Different folks would probably have different definitions, but > > >>> here’s > > >>>> what I think: > > >>>>> > > >>>>> 1. It’s the compiler which turns MXML and ActionScript into > > >>> Javascript. > > >>>>> 2. It’s the paradigm of composing apps using MXML. > > >>>>> 3. It’s a set (or sets) of components which is built with this > > >>> paradigm > > >>>> in mind. (similar to mx and spark components in the classic Flex > > >>> framework.) > > >>>>> 4. It’s the infrastructure which enables tools to take advantage of > > >>> this. > > >>>>> > > >>>>> I think that’s pretty much it. > > >>>>> > > >>>>> Based on this definition, drawing APIs are probably not “Flex > > >>> core”. In > > >>>> fact, some of the other packages which already exist are probably > also > > >>> not > > >>>> Flex core (such as GoogleMaps). > > >>>>> > > >>>>> These are all useful things, but trying to include all useful > things > > >>>> will cause a lot of bloat and actually probably stunt community > > >>> growth. > > >>>> Until our focus was how to grow the Apache Flex community. I think > > >>> we’ve > > >>>> come to a bit of a cross-roads here, and we need to figure out how > to > > >>> help > > >>>> grow the community OUTSIDE Apache. > > >>>>> > > >>>>> What would accepting these APIs accomplish? I think primarily three > > >>>> things: > > >>>>> 1. Give the APis visibility. > > >>>>> 2. Help promote others to work on them. > > >>>>> 3. Make it easy for clients to use them. > > >>>>> > > >>>>> These are generalized problems and I think we need to solve them in > > >>> a > > >>>> generalized way so the next person who comes up with some other > > >>> awesome > > >>>> classes will have these problems solved as well. If someone builds > > >>> some > > >>>> cool stuff around FlexJs, we should not need discussion to make them > > >>> useful > > >>>> and usable. > > >>>>> > > >>>>> Here’s some ideas I came up with while thinking about this: > > >>>>> > > >>>>> 1. We need a way to find tools and libraries that support FlexJS. > > >>>>> 2. We need to help external libraries automate builds of swcs. I > > >>> think > > >>>> it would be really useful to publish some docs with a recommended > > >>> workflow > > >>>> for Github to do this. > > >>>>> 3. We need some kind of central repository of FlexJS swcs outside > > >>>> Apache. There should probably be two classes of swcs. Ones that are > > >>>> strictly externs, and others which actually compile into Javascript > > >>> code. > > >>>>> 4. I think we need a system to create an automated build of > > >>> Definitely > > >>>> Typed definitions into FlexJS swcs into a centralized repo. I think > > >>> Github > > >>>> has hooks you can use to trigger things when their repo changes. > > >>>>> > > >>>>> If these four points are addressed, I think it’ll do a lot to build > > >>> the > > >>>> greater community without adding all kinds of peripherals into the > > >>> core > > >>>> FlexJS repo. (and much more effectively as well) It’s not necessary > > >>> for > > >>>> Apache Flex to address all these directly. If the community at large > > >>>> addresses some of them, that’s also fine (or maybe even better). > > >>>>> > > >>>>> Harbs > > >>>>> > > >>>>> On Apr 19, 2016, at 6:39 PM, Josh Tynjala <joshtynj...@gmail.com> > > >>> wrote: > > >>>>> > > >>>>>> I've always thought that someone implementing the Flash classes is > > >>> a > > >>>> good > > >>>>>> idea, but that it makes the most sense as an external project. In > > >>> other > > >>>>>> words, not included with Apache FlexJS. There's nothing wrong with > > >>>> external > > >>>>>> projects. In fact, they're a sign of a healthy community! We > > >>> should be > > >>>>>> encouraging them and promoting them. > > >>>>>> > > >>>>>> I agree with Alex's points that including the Flash classes in > > >>> FlexJS > > >>>> will > > >>>>>> set expectations of compatibility that may not be desirable from > > >>> our > > >>>> side. > > >>>>>> It also keeps FlexJS bound to the legacy of Flash, instead of > > >>> showing > > >>>> that > > >>>>>> the project is evolving into something new and interesting. > > >>>>>> > > >>>>>> - Josh > > >>>>>> > > >>>>>> On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui <aha...@adobe.com> > > >>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 4/19/16, 12:01 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > >>>>>>> > > >>>>>>>> webgl is not a very good name, because a lot of the code is > > >>> actually > > >>>>>>>> canvas rather than webgl. > > >>>>>>> > > >>>>>>> OK. I realized that Lizhi has been calling it SpriteFlexJS. So > > >>> that > > >>>>>>> could be in the package name. > > >>>>>>> > > >>>>>>> Actually this might be a good time to discuss names in terms of > > >>>> business > > >>>>>>> models. Lizhi, I want to make sure you are aware that whatever > > >>> name > > >>> we > > >>>>>>> put on your code base will belong to Apache and you won't be able > > >>> to > > >>>> sell > > >>>>>>> software using that name. This is a public mailing list, so feel > > >>> free > > >>>> to > > >>>>>>> not answer or write me directly, but an important point is this: > > >>> I'm > > >>>> not > > >>>>>>> sure how you plan to keep contributing to the SpriteFlexJS code, > > >>> but > > >>>> if it > > >>>>>>> involves selling the software what most people do is come up with > > >>> two > > >>>>>>> names, one for the for-profit software and one for the open > source > > >>> code > > >>>>>>> base. For example, the Apache Subversion project doesn't let > > >>> other > > >>>>>>> for-profit products be called Subversion, but they can use SVN. > > >>> Adobe > > >>>>>>> PhoneGap is a for-profit product based on Apache Cordova. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> What might make more sense would be to keep all the flash > > >>> packages > > >>> as > > >>>>>>>> experimental, and if we can identify robust piece of the > > >>> package, we > > >>>> can > > >>>>>>>> repurpose some of the code to be in separate packages. > > >>>>>>> > > >>>>>>> Another option is that we don't bring in all of this code right > > >>> away. > > >>>>>>> Didn't this thread start based on interest in Lizhi's ByteArray? > > >>> Lizhi > > >>>>>>> could donate that one file and we could use it under a different > > >>>> package > > >>>>>>> name. > > >>>>>>> > > >>>>>>>> > > >>>>>>>> I see value in keeping the flash packages as such, because it > > >>> will > > >>>> likely > > >>>>>>>> help spur more people who want complete “flash-like” APIs to do > > >>> work > > >>>> on > > >>>>>>>> it. As Lizhi points out, there are incomplete areas in his code. > > >>>>>>>> > > >>>>>>>> As far as demand for Flash and Starling goes: I expect that > folks > > >>> who > > >>>>>>>> want more support will have to help out in improving it. Again, > I > > >>> hope > > >>>>>>>> this will help attract more people to work on it. > > >>>>>>> > > >>>>>>> In short, I'm just wondering if the work on Flash and Starling is > > >>> Flex. > > >>>>>>> Should it have its own community? FlexJS will hopefully have > many > > >>>>>>> customers and not all of their code should be in our code base. > > >>>>>>> > > >>>>>>> -Alex > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > > > > >
