flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Date Tue, 19 Apr 2016 23:04:35 GMT
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?


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
> 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
> >>>
> >>>
> >

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