flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Date Sun, 08 May 2016 23:41:04 GMT
+1 for the renaming to typedefs or anything but "externs"


Von: Harbs <harbs.lists@gmail.com>
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 <christofer.dutz@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.lists@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
> 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.dutz@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.lists@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
>> 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 <aharui@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" <joshtynjala@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
>>>> <bigosmallm@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.lists@gmail.com>
>>>>>> 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.lists@gmail.com>
>>>>>>> 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.
>>>>> 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 <joshtynjala@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.
>>>>> other
>>>>>>>> words, not included with Apache FlexJS. There's nothing wrong
>>>>>>>> with
>>>>>> external
>>>>>>>> projects. In fact, they're a sign of a healthy community!
>>>>> should be
>>>>>>>> encouraging them and promoting them.
>>>>>>>> I agree with Alex's points that including the Flash classes
>>>>> FlexJS
>>>>>> will
>>>>>>>> set expectations of compatibility that may not be desirable
>>>>> our
>>>>>> side.
>>>>>>>> It also keeps FlexJS bound to the legacy of Flash, instead
>>>>> showing
>>>>>> that
>>>>>>>> the project is evolving into something new and interesting.
>>>>>>>> - Josh
>>>>>>>> On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui <aharui@adobe.com>
>>>>> wrote:
>>>>>>>>> On 4/19/16, 12:01 AM, "Harbs" <harbs.lists@gmail.com>
>>>>>>>>>> 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.
>>>>> 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
>>>>> name
>>>>> we
>>>>>>>>> put on your code base will belong to Apache and you won't
>>>>>>>>> able
>>>>> to
>>>>>> sell
>>>>>>>>> software using that name.  This is a public mailing list,
>>>>>>>>> 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
>>>>> 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
>>>>>>>>> source
>>>>> code
>>>>>>>>> base.  For example, the Apache Subversion project doesn't
>>>>> 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
>>>>> 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
>>>>> 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
>>>>>>>>>> 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
>>>>>>>>> is
>>>>> Flex.
>>>>>>>>> Should it have its own community?  FlexJS will hopefully
>>>>>>>>> many customers and not all of their code should be in
our code base.
>>>>>>>>> -Alex

View raw message