I like the sound of "typedef SWCs" better than "extern SWCs". The meaning of the name is more obvious, I think.
- Josh On May 8, 2016 9:35 AM, "Harbs" <harbs.li...@gmail.com> wrote: FWIW, I was reflecting on the naming a bit more today, and I’m thinking that “FlexJS Typedefs” or “FlexJS Type Definitions” might be better than “FlexJS Externs”. I think typedefs are more descriptive than “externs”. On the other hand, “externs” is a terminology already used by GCC. The diagram should possibly further break down the components to “core” FlexJS and “community” swcs of both kinds. On May 8, 2016, at 3:27 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > Hi Harbs, > > thanks for writing and drawing this up. It exactly matches my impression and it exactly matches the naming convention I used for the Mavenization as I used the following group Ids: > org.apache.flex.flexjs.compiler > org.apache.flex.flexjs.framewort > org.apache.flex.flexjs.extern > > I too think we should call the whole thing "FlexJS" even if it's not 100% accurate. But from my impression I'd rather take an "Aspririn" even if it's a generic clone than the correct form of taking some "Acetylsalicylic Acid" ;-) > > I think it's easier to explain people in how far the link between the two is not 100% than to explain everybody why the FlexJS SDK consists of a set of differently named tools. > > Chris > ________________________________________ > Von: Harbs <harbs.li...@gmail.com> > Gesendet: Sonntag, 8. Mai 2016 12:17:41 > An: dev@flex.apache.org > Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs > > I don’t want to let this discussion die, because I think it’s important. > > I think this naming strategy is a good one. > > I put together a wiki page to help explain and help visualize the different pieces[1] > > I’m not sure that it’s all 100% accurate. Feel free to edit for accuracy and general improvements. > > I created a new page because I did not want to totally mess up the content on this page[2] > > Harbs > > [1]https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Parts > [2]https://cwiki.apache.org/confluence/display/FLEX/FlexJS > > On Apr 21, 2016, at 11:27 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > >> When creating maven artifacts from SDKs we had a different naming, which I find a little more intuitive. >> Applied to FlexJS instead of Flex, this would be: >> >> FlexJS Compiler: Falcon, FalconJX >> FlexJS Framework: ASJS >> FlexJS Externs: Externs >> >> How about this .. but I agree in the part where you call call Falcon something FlexJS ;-) >> >> Chris >> >> -----Ursprüngliche Nachricht----- >> Von: Harbs [mailto:harbs.li...@gmail.com] >> Gesendet: Donnerstag, 21. April 2016 16:41 >> An: dev@flex.apache.org >> Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs >> >> I think we're all in agreement that FalconJX without the rest is an important part even on its own. That's what I meant by #1. >> >> I do think that naming is important. It helps "brand" a product. Something like MXMLC2.0 is way too techie to be a "product". >> >> I've been thinking of different ways to "brand" this, and I think I have an idea which might work: >> >> Falcon and FalconJX and related toolchain which compiles AS and optionally MXML into swc, swf and js could be branded as "FlexJS Core". >> >> Everything else which is really about components and UI could be branded as "FlexJS UI". >> >> This is really similar to how JQuery did it with JQuery and JQuery UI. >> >> This would give a central brand, while preserving the concept that you can use the compiler without the component sets (or even MXML at all). >> >> Harbs >> >> On Apr 20, 2016, at 8:02 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> Good thoughts in this thread. >>> >>> My current thinking is this: >>> >>> FalconJX is a code name for the cross-compiler, but because there is >>> an Apache Falcon project, we need a better product name, and consider >>> that Falcon may someday compile SWFs for the Flex SDK. Adobe already >>> used ASC2.0, plus our version of Falcon handles MXML. We could use >>> MXMLC2.0, but I'm not a huge fan of that. >>> >>> IMO, FlexJS has become a tool chain. It takes in MXML and AS and >>> outputs SWFs or HTML/JS/CSS. We want to draw in every JS framework >>> community to MXML-enable their components. Peter is hoping to finish >>> a demo soon of how much easier it is to learn and use CreateJS with >>> MXML than with the current CreateJS tutorials in JS. Maybe that will >>> get the ball rolling downhill. >>> >>> We will still build out a Basic component set for lowest-level >>> smallest-footprint apps. And we hope to build out MX and Spark-like >>> component sets to ease migration pain for existing Flex code bases. >>> >>> Yes, we have CreateJS, Jquery and GoogleMaps SWCs now, mostly as >>> proofs-of-concept. I hope to see the respective communities take over >>> development of these SWCs and expect them to do it outside of our >>> repos, and have independent release schedules. >>> >>> So that's why I'm not sure a component set that targets Stage3D and >>> Starling has to be part of this community. It can certainly be a >>> customer of the FlexJS tool chain, and we want it to be a customer, >>> but we want all JS component set communities to be customers of FlexJS >>> whether they build for SWF-first workflows or direct-to-JS workflows. >>> >>> Further down the road, once FlexJS grows to support distributed >>> development, we will be able to more clearly show the benefit of >>> SWF-first workflows for those who need it. But that's for another thread someday. >>> >>> My 2 cents, >>> -Alex >>> >>> On 4/19/16, 4:52 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: >>> >>>> I agree that FalconJX without the FlexJS framework is an important >>>> use case. That's basically why I'm here contributing to the project. >>>> I want to champion the ActionScript language, and show how FalconJX >>>> will let you use ActionScript anywhere that JavaScript is supported. >>>> That means (now or >>>> eventually) working with HTML, Node.js, Electron, and extensibility >>>> APIs the like CEP panels that Harbs mentioned. >>>> >>>> For this use case, I think it's all about focusing on building a >>>> solid compiler. >>>> >>>> - Josh >>>> >>>> On Tue, Apr 19, 2016 at 4:04 PM, OmPrakash Muppirala >>>> <bigosma...@gmail.com> >>>> wrote: >>>> >>>>> We have an equally important component that is FalconJX. I envision >>>>> lot of demand to work on non-FlexJS, pure FalconJX work. >>>>> >>>>> I think the Starling port falls under the category of pure FalconJX >>>>> work and not FlexJS. We already have a game company working on >>>>> making a game using the FalconJX compiler. >>>>> >>>>> Any thoughts on how we want to handle this use case? >>>>> >>>>> Thanks, >>>>> Om >>>>> >>>>> On Tue, Apr 19, 2016 at 3:44 PM, Harbs <harbs.li...@gmail.com> wrote: >>>>> >>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >> >
