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