Hi Harbs, thanks for writing and drawing this up. It exactly matches my impression and it exactly matches the naming convention I used for the Mavenization as I used the following group Ids: org.apache.flex.flexjs.compiler org.apache.flex.flexjs.framewort org.apache.flex.flexjs.extern
I too think we should call the whole thing "FlexJS" even if it's not 100% accurate. But from my impression I'd rather take an "Aspririn" even if it's a generic clone than the correct form of taking some "Acetylsalicylic Acid" ;-) I think it's easier to explain people in how far the link between the two is not 100% than to explain everybody why the FlexJS SDK consists of a set of differently named tools. Chris ________________________________________ Von: Harbs <harbs.li...@gmail.com> Gesendet: Sonntag, 8. Mai 2016 12:17:41 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs I don’t want to let this discussion die, because I think it’s important. I think this naming strategy is a good one. I put together a wiki page to help explain and help visualize the different pieces[1] I’m not sure that it’s all 100% accurate. Feel free to edit for accuracy and general improvements. I created a new page because I did not want to totally mess up the content on this page[2] Harbs [1]https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Parts [2]https://cwiki.apache.org/confluence/display/FLEX/FlexJS On Apr 21, 2016, at 11:27 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > 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 >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>>> >> >
