When creating maven artifacts from SDKs we had a different naming, which I find a little more intuitive. Applied to FlexJS instead of Flex, this would be:
FlexJS Compiler: Falcon, FalconJX FlexJS Framework: ASJS FlexJS Externs: Externs How about this .. but I agree in the part where you call call Falcon something FlexJS ;-) Chris -----Ursprüngliche Nachricht----- Von: Harbs [mailto:harbs.li...@gmail.com] Gesendet: Donnerstag, 21. April 2016 16:41 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs 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 >>>>>>> >>>>>>> >>>>> >>>> >>>> >>> >
