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 > > >>> > > >>> > > > > > > > >
