And what about calling that stuff "Flex 5"? We'd have the flex5 compiler (aka Falcon), framework (aka ASJS) ...
Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Mittwoch, 20. April 2016 07:02 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs 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 >> > >>> >> > >>> >> > > >> > >> > >>
