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