flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Tynjala <joshtynj...@gmail.com>
Subject Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Date Sun, 08 May 2016 22:48:32 GMT
I like the sound of "typedef SWCs" better than "extern SWCs". The meaning
of the name is more obvious, I think.

- Josh
On May 8, 2016 9:35 AM, "Harbs" <harbs.lists@gmail.com> wrote:

FWIW, I was reflecting on the naming a bit more today, and I’m thinking
that “FlexJS Typedefs” or “FlexJS Type Definitions” might be better than
“FlexJS Externs”. I think typedefs are more descriptive than “externs”. On
the other hand, “externs” is a terminology already used by GCC.

The diagram should possibly further break down the components to “core”
FlexJS and “community” swcs of both kinds.

On May 8, 2016, at 3:27 PM, Christofer Dutz <christofer.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 improvements.
>
> I created a new page because I did not want to totally mess up the
content on this page[2]
>
> Harbs
>
> [1]https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Parts
> [2]https://cwiki.apache.org/confluence/display/FLEX/FlexJS
>
> On Apr 21, 2016, at 11:27 PM, Christofer Dutz <christofer.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 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 <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>
wrote:
>>>>>
>>>>>> I missed a fifth item in my list of things we need:
>>>>>> 5. We need tooling to pull in external swcs (externs and
>>>>> cross-copiling
>>>>>> ones) when compiling to Javascript.
>>>>>>
>>>>>> (I think we also need a naming convention for the two types of swcs.
>>>>>> "definition swcs" and "code swcs"?)
>>>>>>
>>>>>> On Apr 20, 2016, at 1:37 AM, Harbs <harbs.lists@gmail.com>
wrote:
>>>>>>
>>>>>>> Alex and Josh bring up good points.
>>>>>>>
>>>>>>> I'm thinking that I should step back and figure out what I was
>>>>> trying
>>>>> to
>>>>>> accomplish by suggesting that we accept these APIs.
>>>>>>>
>>>>>>> In fact, I think it's time we figure out exactly what FlexJS
>>>>> actually
>>>>> is.
>>>>>>>
>>>>>>> The motivation to accept the code into FlexJS was really to
>>>>>>> empower
>>>>>> users to have access to great APIs and capabilities. However to say
>>>>> that
>>>>>> any cool functionality should become part of the core product
>>>>>> probably
>>>>> does
>>>>>> not make sense. Case in point: I'm currently working on FlexJS
>>>>>> support
>>>>> for
>>>>>> CEP panels in Adobe extensions. I think it's great functionality,
>>>>>> but
>>>>> I
>>>>>> don't believe it belongs in the Flex repo.
>>>>>>>
>>>>>>> To address the question of exactly what belongs in the FlexJS
>>>>>>> repo,
>>>>> I
>>>>>> think we need to address exactly what is the identity of FlexJS
>>>>> actually
>>>>>> is. Different folks would probably have different definitions, but
>>>>> here's
>>>>>> what I think:
>>>>>>>
>>>>>>> 1. It's the compiler which turns MXML and ActionScript into
>>>>> Javascript.
>>>>>>> 2. It's the paradigm of composing apps using MXML.
>>>>>>> 3. It's a set (or sets) of components which is built with this
>>>>> paradigm
>>>>>> in mind. (similar to mx and spark components in the classic Flex
>>>>> framework.)
>>>>>>> 4. It's the infrastructure which enables tools to take advantage
>>>>>>> of
>>>>> this.
>>>>>>>
>>>>>>> I think that's pretty much it.
>>>>>>>
>>>>>>> Based on this definition, drawing APIs are probably not "Flex
>>>>> core". In
>>>>>> fact, some of the other packages which already exist are probably
>>>>>> also
>>>>> not
>>>>>> Flex core (such as GoogleMaps).
>>>>>>>
>>>>>>> These are all useful things, but trying to include all useful
>>>>>>> things
>>>>>> will cause a lot of bloat and actually probably stunt community
>>>>> growth.
>>>>>> Until our focus was how to grow the Apache Flex community. I think
>>>>> we've
>>>>>> come to a bit of a cross-roads here, and we need to figure out how
>>>>>> to
>>>>> help
>>>>>> grow the community OUTSIDE Apache.
>>>>>>>
>>>>>>> What would accepting these APIs accomplish? I think primarily
>>>>>>> three
>>>>>> things:
>>>>>>> 1. Give the APis visibility.
>>>>>>> 2. Help promote others to work on them.
>>>>>>> 3. Make it easy for clients to use them.
>>>>>>>
>>>>>>> These are generalized problems and I think we need to solve them
>>>>>>> in
>>>>> a
>>>>>> generalized way so the next person who comes up with some other
>>>>> awesome
>>>>>> classes will have these problems solved as well. If someone builds
>>>>> some
>>>>>> cool stuff around FlexJs, we should not need discussion to make
>>>>>> them
>>>>> useful
>>>>>> and usable.
>>>>>>>
>>>>>>> Here's some ideas I came up with while thinking about this:
>>>>>>>
>>>>>>> 1. We need a way to find tools and libraries that support FlexJS.
>>>>>>> 2. We need to help external libraries automate builds of swcs.
I
>>>>> think
>>>>>> it would be really useful to publish some docs with a recommended
>>>>> workflow
>>>>>> for Github to do this.
>>>>>>> 3. We need some kind of central repository of FlexJS swcs outside
>>>>>> Apache. There should probably be two classes of swcs. Ones that are
>>>>>> strictly externs, and others which actually compile into Javascript
>>>>> code.
>>>>>>> 4. I think we need a system to create an automated build of
>>>>> Definitely
>>>>>> Typed definitions into FlexJS swcs into a centralized repo. I think
>>>>> Github
>>>>>> has hooks you can use to trigger things when their repo changes.
>>>>>>>
>>>>>>> If these four points are addressed, I think it'll do a lot to
>>>>>>> build
>>>>> the
>>>>>> greater community without adding all kinds of peripherals into the
>>>>> core
>>>>>> FlexJS repo. (and much more effectively as well) It's not necessary
>>>>> for
>>>>>> Apache Flex to address all these directly. If the community at
>>>>>> large addresses some of them, that's also fine (or maybe even
better).
>>>>>>>
>>>>>>> Harbs
>>>>>>>
>>>>>>> On Apr 19, 2016, at 6:39 PM, Josh Tynjala <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.
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 <aharui@adobe.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/19/16, 12:01 AM, "Harbs" <harbs.lists@gmail.com>
wrote:
>>>>>>>>>
>>>>>>>>>> webgl is not a very good name, because a lot of the
code is
>>>>> actually
>>>>>>>>>> canvas rather than webgl.
>>>>>>>>>
>>>>>>>>> OK.  I realized that Lizhi has been calling it SpriteFlexJS.
 So
>>>>> that
>>>>>>>>> could be in the package name.
>>>>>>>>>
>>>>>>>>> Actually this might be a good time to discuss names in
terms of
>>>>>> business
>>>>>>>>> models.  Lizhi, I want to make sure you are aware that
whatever
>>>>> name
>>>>> we
>>>>>>>>> put on your code base will belong to Apache and you won't
be
>>>>>>>>> able
>>>>> to
>>>>>> sell
>>>>>>>>> software using that name.  This is a public mailing list,
so
>>>>>>>>> feel
>>>>> free
>>>>>> to
>>>>>>>>> not answer or write me directly, but an important point
is this:
>>>>> I'm
>>>>>> not
>>>>>>>>> sure how you plan to keep contributing to the SpriteFlexJS
code,
>>>>> but
>>>>>> if it
>>>>>>>>> involves selling the software what most people do is
come up
>>>>>>>>> with
>>>>> two
>>>>>>>>> names, one for the for-profit software and one for the
open
>>>>>>>>> source
>>>>> code
>>>>>>>>> base.  For example, the Apache Subversion project doesn't
let
>>>>> other
>>>>>>>>> for-profit products be called Subversion, but they can
use SVN.
>>>>> Adobe
>>>>>>>>> PhoneGap is a for-profit product based on Apache Cordova.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What might make more sense would be to keep all the
flash
>>>>> packages
>>>>> as
>>>>>>>>>> experimental, and if we can identify robust piece
of the
>>>>> package, we
>>>>>> can
>>>>>>>>>> repurpose some of the code to be in separate packages.
>>>>>>>>>
>>>>>>>>> Another option is that we don't bring in all of this
code right
>>>>> away.
>>>>>>>>> Didn't this thread start based on interest in Lizhi's
ByteArray?
>>>>> Lizhi
>>>>>>>>> could donate that one file and we could use it under
a different
>>>>>> package
>>>>>>>>> name.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I see value in keeping the flash packages as such,
because it
>>>>> will
>>>>>> likely
>>>>>>>>>> help spur more people who want complete "flash-like"
APIs to do
>>>>> work
>>>>>> on
>>>>>>>>>> it. As Lizhi points out, there are incomplete areas
in his code.
>>>>>>>>>>
>>>>>>>>>> As far as demand for Flash and Starling goes: I expect
that
>>>>>>>>>> folks
>>>>> who
>>>>>>>>>> want more support will have to help out in improving
it. Again,
>>>>>>>>>> I
>>>>> hope
>>>>>>>>>> this will help attract more people to work on it.
>>>>>>>>>
>>>>>>>>> In short, I'm just wondering if the work on Flash and
Starling
>>>>>>>>> is
>>>>> Flex.
>>>>>>>>> Should it have its own community?  FlexJS will hopefully
have
>>>>>>>>> many customers and not all of their code should be in
our code
base.
>>>>>>>>>
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message