webgl is not a very good name, because a lot of the code is actually canvas rather than webgl.
I think that expectations can be set using documentation. We can label flash packages as “experimental” or something similar, so clients would be aware that it will likely be incomplete. 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. 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. The legal concerns of using the flash package name seems really far-fetched to me. On Apr 19, 2016, at 8:56 AM, Alex Harui <aha...@adobe.com> wrote: > Warning: I can't decide if I'm just playing devil's advocate or am truly > concerned about this, but below are some worst-case scenarios, which may > need to be taken with a grain of salt. > > My latest proposal is that we rename packages from "flash.* to "webgl.*" > and teach the compiler how to map things. And maybe also update the > reflection library to be aware that there was a mapping. We might end up > having the compiler do this sort of thing to migrate Flex code bases as > well. Yes, it may mean that migration isn't automatic. But IMO, until we > find a clean way to do weak references in JS, there is going to have to be > some migration pain. > > On 4/18/16, 6:47 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" > <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >> >> We already have package names like jquery.*.* and createjs.*.* where we >> are >> using the same package names for consistency. Are we proposing to change >> all those package names as well, so that we dont set expectations of doing >> everything that jquery does? > > The jquery and createjs implementations actually use Jquery and CreateJS > on the JS side, so it should meet expectations. > > There is a potential outcome where we end up having more demand for Flash > emulation in JS than Flex. Or spending more time on Starling than on > Flex. If that's where the community wants to go, I can't stop it, but > this project is called Flex. And, IMO, the big money is in enterprise > code bases in Flex. > >> >> If it turns out that that lot of folks complain about the classes not >> meeting the expectations, we could probably add the features or worst case >> swap the package names to flex.* > > We can change the package names and have the compiler do-the-right thing. > If we set the precedence of using "flash" it will be harder to change in > the future. We'll get backwards compatibility complaints and the search > engines will turn up "flash" stuff for a long time. When I think about > the person-hours devoted to Flash at Adobe, it is hard to imagine this > community finding the time to even do a fraction of that investment. It > seemed like even Google was having trouble making Pepper Flash a true > equivalent. > > And there might be increased legal issues due to things like this [1]. > > -Alex > > [1] http://blog.smartbear.com/apis/api-copyright-and-why-you-should-care/ > > >
