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