But Flex is based on the Flash runtime and underlying API. Without the drawing commands, the interactive layer, point classes, event management, byte array, birthday data, mouse events, etc Flex and other frameworks wouldn't be possible.
The Flash layer and related classes are what Flex is built on. The point of Flex JS is to run on both Flash and the browser so it's not entirely new. Flash is the foundation for one of those targets. we know what to expect from it. With Flex js the goal is to build the exact same house visually and functionally on two aspirate foundations. one is tried and true and the new one we're still building from the ground up. But for this to work those two foundations need to be identical IMHO. I wouldn't be opposed to having Apache Flex projects using external libraries from Github. But in some capacity we would need the same quality control, testing and licensing. I don't know if you can do that with an external library. I wouldn't worry about expectations and that shouldn't be an excuse. We deal with them all the time anyway. Apache was kind enough to give us a canned response, "If you have an itch scratch it yourself. If it's broke fix it yourself." since we aren't a corporate identity we can easily add a disclaimer, "this project is run by volunteers. The full Flash api is not supported. The project is open source. feel free to jump in and add missing pieces" on another note, this project could benefit from corporate sponsors and endorsements. feature and bug fixing bounties could help bring in the freelancer crowd. filling in the missing api would be quickly solved. ... if anyone knows how to do this or know someone that does then we need to get them on board. ...side tracked again, but I bring this up bc I know developers who would help this project along given endorsements, sponsorship, branding, etc. in the same way angular is popular even though it has so many issues. The main reason it is is because Google endorses it. On Apr 19, 2016 10:40 AM, "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 > > > > >
