On 4/19/16, 5:08 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>I think there's some disagreement about the abstraction level where the >FlexJS framework lives. I've always understood that it lived at the >component level. Buttons, lists, sliders, data grids, etc. Emulating Flash >drawing APIs seems like a lower level to me. I feel like we should use the >Flash drawing APIs with Flash, but whatever is best for other targets. > >There are downsides of forcing everything to emulate the Flash APIs. For >instance, it may hurt performance in some environments. My current vision for FlexJS is to remove any Flash-like APIs from the API surface because they are hard/expensive/impossible to implement in the JS runtime. In doing so, we try to abstract away whether there is a timeline or not, we don't use weak references or Dictionary, we don't promise deferred rendering (changing the display list in JS is immediate in most cases). Otherwise, the cost to implement and run is just too high. At least, I haven't figured out any way to implement weak references or deferred rendering without a ton of work that will eat battery life. IMO, for the basic set of FlexJS components, the goal is to make the JS version smaller and faster than the SWF version when forced to make a choice. So the basic component set leverages HTMLElement when it can. Now, the Spark/MX-like component sets, assuming we can get them to work, probably will support a flash.display.Graphics object sort of thing. It doesn't care so much about size and performance. Its main goal is to minimize the API surface changes from the current Flex SDK, but it will probably leak memory: folks will have to make API calls since we don't have weak references. IMO, emulating Flash on JS is for a different community. We have enough work just trying to get the code we have to 1.0. There are probably some great things in Lizhi's code that will be useful to us, but I think our target market is more about enterprise customers sitting on large Flex code bases than on Starling. I'll say more on the bigger picture in the Identity Crisis thread. -Alex > >- Josh > >On Tue, Apr 19, 2016 at 3:09 PM, jude <flexcapaci...@gmail.com> wrote: > >> 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 >> > > >> > > >> > >>
