Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Good page, Harbs. We should move it under the FlexJS tree somewhere. I have no objections to changing "externs" to something else. One nit: it says externs are "linked at compile-time". Might be better to say, "used for type-checking at compile-time". Thanks, -Alex
AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
+1 for the renaming to typedefs or anything but "externs" Chris Von: Harbs Gesendet: Sonntag, 8. Mai 2016 18:35:36 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs 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 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 > 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 > 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 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 SW
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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" 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 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 > 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 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 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 wi
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 > 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 > 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 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 tha
AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 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 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
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 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 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" 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 ext
Re: AW: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On 4/23/16, 2:12 AM, "Christofer Dutz" wrote: >Hi Alex ... > >first ... the official name should probably even contain the "Apache >Flex" so I guess the correct name would probably be "Apache Flex FlexJS >Compiler" We are trying to establish FlexJS and Apache FlexJS as trademarks, so I don't think we "have to" prefix with "Flex" or "Apache Flex". But AIUI, it is up to us to decide. > >The names don't really matter for maven ... we could call them "js" and >Maven would be fine with them, but I tend to give my artifacts a little >more context. For example if we name the jquery extern "jquery" then >there is the "jquery" framework project of ASJS with the same name. Of >course I would give both a different groupId, but still it will probably >cause a little more problems. If we name the artifacts >"flexjs-externs-jquery" and "flexjs-framework-jquery" the context is >well-defined. But If the majority wants the "jquery" artifactId for both, >I would simply adjust the artifactIds. One answer I thought of was that our downloadable packages start with "apache-flex" or "apache-flexjs", but internal stuff can have short names. That's sort of how flex-sdk and flex-asjs do it today. The SWCs bundled inside the binary package have short names like spark.swc and Core.swc. Or would that be confusing for Maven users if they are pulling down their Core.swc as apache-flexjs-core-0.7.0.swc? Maybe they want the longer names to be sure what version they are on? -Alex
AW: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Hi Alex ... first ... the official name should probably even contain the "Apache Flex" so I guess the correct name would probably be "Apache Flex FlexJS Compiler" The names don't really matter for maven ... we could call them "js" and Maven would be fine with them, but I tend to give my artifacts a little more context. For example if we name the jquery extern "jquery" then there is the "jquery" framework project of ASJS with the same name. Of course I would give both a different groupId, but still it will probably cause a little more problems. If we name the artifacts "flexjs-externs-jquery" and "flexjs-framework-jquery" the context is well-defined. But If the majority wants the "jquery" artifactId for both, I would simply adjust the artifactIds. Chris Von: Alex Harui Gesendet: Freitag, 22. April 2016 20:40 An: dev@flex.apache.org Betreff: Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs On 4/21/16, 1:27 PM, "Christofer Dutz" 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 ;-) Seems ok to me. The true official full name has to start with Apache though: "Apache FlexJS Compiler". I don't know if you can leave "apache" off the artifact names. Related to this, I noticed in the Maven builds, the SWCs are getting longer names as well. So what we've been referring to as "js.swc" is now "flexjs-externs-js-0.6.0.swc" and may have to be called "apache-flexjs-externs-js-0.6.0.swc". I guess I can see how that might be important for Maven, but I'm just wondering about having to use the longer name in the documentation and other places like the IDE library path dialogs. Maybe the Ant builds and IDE installers should go with shorter names? Thoughts? -Alex
AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
What about simply naming the compiler "FlexJS Compiler"? Currently the maven plugin for example has a reference to falcon.jx and falcon and selects the right compc version using the Flex Tool Group API. So having different variants inside the compiler package doesn't seem too confusing. Anyway the compiler should compile to Flash and compiler-jx can compile to flash and html5. From the scenarios you could use the compiler package: 1. Compile normal Flex applications to Flash 2. Compiler FlexJS to Flash and HTML5 using the FlexJS Framwork 3. Compiler FlexJS to HTML5 using external frameworks I think the use case 1 will be the one that's going to die out and the name FlexJS compiler for use case 2 and 3 sounds like a good match. Chris Von: Josh Tynjala Gesendet: Samstag, 23. April 2016 03:02 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs FlexJS is a good name for the framework, and changing it will cause unnecessary confusion. At this point, most people are going to be primarily targeting JavaScript anyway. - Josh On Apr 22, 2016 4:55 PM, "jude" wrote: > Flex JS conveys Flex as JavaScript framework but it's a hybrid really. > Could we reflect that Flex JS is a hybrid someway? > > Flex js is a sort of refactor. maybe: > > Flex Reactor > ReFlex > Flexo > Flex Nano > Flex Red > Flex Inc > Flexenstein > Flex Int > Flex passport > Flex Axiom > Flex Ion > Flex Action > > I don't know. > > There used to be a graph that showed how everything related to everything > else. But with Falcon, FlexJS, Falcon JX and so on it which have been added > after those graphs it can be confusing. Anyone want to draw something > updated under the new Apache Flex Platform? > > On Apr 21, 2016 9:41 AM, "Harbs" wrote: > > > > 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 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 w
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
FlexJS is a good name for the framework, and changing it will cause unnecessary confusion. At this point, most people are going to be primarily targeting JavaScript anyway. - Josh On Apr 22, 2016 4:55 PM, "jude" wrote: > Flex JS conveys Flex as JavaScript framework but it's a hybrid really. > Could we reflect that Flex JS is a hybrid someway? > > Flex js is a sort of refactor. maybe: > > Flex Reactor > ReFlex > Flexo > Flex Nano > Flex Red > Flex Inc > Flexenstein > Flex Int > Flex passport > Flex Axiom > Flex Ion > Flex Action > > I don't know. > > There used to be a graph that showed how everything related to everything > else. But with Falcon, FlexJS, Falcon JX and so on it which have been added > after those graphs it can be confusing. Anyone want to draw something > updated under the new Apache Flex Platform? > > On Apr 21, 2016 9:41 AM, "Harbs" wrote: > > > > 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 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" 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 > > >> > > >> 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? > > >>>
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Flex JS conveys Flex as JavaScript framework but it's a hybrid really. Could we reflect that Flex JS is a hybrid someway? Flex js is a sort of refactor. maybe: Flex Reactor ReFlex Flexo Flex Nano Flex Red Flex Inc Flexenstein Flex Int Flex passport Flex Axiom Flex Ion Flex Action I don't know. There used to be a graph that showed how everything related to everything else. But with Falcon, FlexJS, Falcon JX and so on it which have been added after those graphs it can be confusing. Anyone want to draw something updated under the new Apache Flex Platform? On Apr 21, 2016 9:41 AM, "Harbs" wrote: > > 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 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" 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 > >> > >> 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 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 wrote: > > > Alex and
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Hi, > Seems ok to me. The true official full name has to start with Apache > though: "Apache FlexJS Compiler". I don't know if you can leave "apache" > off the artifact names. It’s recommended we use the full name with Apache in it [1] for trademark/legal reasons. See also branding and trademark policy pages for further information. Thanks, Justin 1. http://incubator.apache.org/guides/releasemanagement.html#naming
Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Yeah, long file names like that are very unappealing. We need to try to avoid that situation. - Josh On Apr 22, 2016 11:40 AM, "Alex Harui" wrote: > > > On 4/21/16, 1:27 PM, "Christofer Dutz" 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 ;-) > > Seems ok to me. The true official full name has to start with Apache > though: "Apache FlexJS Compiler". I don't know if you can leave "apache" > off the artifact names. > > Related to this, I noticed in the Maven builds, the SWCs are getting > longer names as well. So what we've been referring to as "js.swc" is now > "flexjs-externs-js-0.6.0.swc" and may have to be called > "apache-flexjs-externs-js-0.6.0.swc". I guess I can see how that might be > important for Maven, but I'm just wondering about having to use the longer > name in the documentation and other places like the IDE library path > dialogs. Maybe the Ant builds and IDE installers should go with shorter > names? > > Thoughts? > -Alex > >
Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On 4/21/16, 1:27 PM, "Christofer Dutz" 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 ;-) Seems ok to me. The true official full name has to start with Apache though: "Apache FlexJS Compiler". I don't know if you can leave "apache" off the artifact names. Related to this, I noticed in the Maven builds, the SWCs are getting longer names as well. So what we've been referring to as "js.swc" is now "flexjs-externs-js-0.6.0.swc" and may have to be called "apache-flexjs-externs-js-0.6.0.swc". I guess I can see how that might be important for Maven, but I'm just wondering about having to use the longer name in the documentation and other places like the IDE library path dialogs. Maybe the Ant builds and IDE installers should go with shorter names? Thoughts? -Alex
AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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" 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 >> >> 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 wrote: >>> >>>> I missed a fifth item in my list of things we need: >>>&
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 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" 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 >> >> 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 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 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
RE: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Sounds like that ASP 5... wait I mean ASP Core v1.0. -Mark -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Wednesday, April 20, 2016 12:47 PM To: dev@flex.apache.org Subject: [Non-DoD Source] Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs Possible, but IMO, Flex 5 implies more backward-compatibility than FlexJS can currently deliver.
Re: AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On 4/20/16, 7:16 AM, "Christofer Dutz" wrote: >And what about calling that stuff "Flex 5"? > >We'd have the flex5 compiler (aka Falcon), framework (aka ASJS) ... Possible, but IMO, Flex 5 implies more backward-compatibility than FlexJS can currently deliver. That said, as I've been working on the Spark/MX-like component set, it as occurred to me that some day, when some JS runtime decides to support weak references and maybe object keys, and if we are otherwise successful getting Spark/MX-like components to run in FlexJS, that if the performance overhead of the work required to get that code to run is small enough, we could "re-base" the flex-sdk repo on top of flex-asjs classes and that would truly be a Flex 5 sort of thing. So in my mind, I'm saving Flex 5 for that day. Also, I'm not sure we are going to wait for the Spark/MX-like component set to declare FlexJS as a 1.0, so I'm still thinking we want a different name. I like having the "JS" in the product name because I think "JS" are important initials to make it clear that this product is for JS app development. Also, there is so many examples about Flex for Flash in the internet, I'd rather not use just "Flex" for content related to producing JS apps because existing examples often mention Flash and could be confusing for folks, and I want to encourage newbies to start with the Basic component set or 3rd-party component sets and not MX or Spark as MX and Spark are likely to be heavy and slow. I also forgot to mention in my last post, that while it is great to have new folks helping out, and it may sound like we have people working on the important things, we could always use more help! If you are reading this, you can help just by trying it out, filing bugs, offering improvements on the documentation, blogging about it, and hopefully, submitting code patches. All those things help make FlexJS ready a bit sooner. Thanks, -Alex
AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
And what about calling that stuff "Flex 5"? We'd have the flex5 compiler (aka Falcon), framework (aka ASJS) ... Chris Von: Alex Harui Gesendet: Mittwoch, 20. April 2016 07:02 An: dev@flex.apache.org Betreff: Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs 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" 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 > >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 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 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 >>
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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" 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 > >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 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 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 pr
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 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 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 ev
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On Tue, Apr 19, 2016 at 3:37 PM, Harbs wrote: > 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. > My dts2as utility can't handle the full repository yet, so if this were to happen, it would need to be a subset of known compatible libraries in the repository. - Josh
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On Tue, Apr 19, 2016 at 3:44 PM, Harbs 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. > When you say tooling, do you mean some kind of package management system for downloading SWCs? Or something else? > (I think we also need a naming convention for the two types of swcs. > "definition swcs" and "code swcs”?) > > Well, we've all been calling the SWCs that define JavaScript APIs "externs SWCs". I'm happy to stick with that name. - Josh
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 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 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 intere
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 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 wrote: >> >>> >>> >>> On 4/19/16, 12:01 AM, "Harbs" 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 th
FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
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 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 wrote: > >> >> >> On 4/19/16, 12:01 AM, "Harbs" 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.
