Re: [Discuss]Accept donation of drawing APIs

[lizhi]

flash api,it is just a api,design good.it will not hurt performance.
the api always not hurt performance



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52503.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [Discuss]Accept donation of drawing APIs

[Josh Tynjala]

I think there's some disagreement about the abstraction level where the
FlexJS framework lives. I've always understood that it lived at the
component level. Buttons, lists, sliders, data grids, etc. Emulating Flash
drawing APIs seems like a lower level to me. I feel like we should use the
Flash drawing APIs with Flash, but whatever is best for other targets.

There are downsides of forcing everything to emulate the Flash APIs. For
instance, it may hurt performance in some environments.

- Josh

On Tue, Apr 19, 2016 at 3:09 PM, jude  wrote:

> But Flex is based on the Flash runtime and underlying API. Without the
> drawing commands, the interactive layer, point classes, event management,
> byte array, birthday data, mouse events, etc Flex and other frameworks
> wouldn't be possible.
>
> The Flash layer and related classes are what Flex is built on.
>
> The point of Flex JS is to run on both Flash and the browser so it's not
> entirely new. Flash is the foundation for one of those targets. we know
> what to expect from it. With Flex js the goal is to build the exact same
> house visually and functionally on two aspirate foundations. one is tried
> and true and the new one we're still building from the ground up. But for
> this to work those two foundations need to be identical IMHO.
>
> I wouldn't be opposed to having Apache Flex projects using external
> libraries from Github. But in some capacity we would need the same quality
> control, testing and licensing. I don't know if you can do that with an
> external library.
>
> I wouldn't worry about expectations and that shouldn't be an excuse. We
> deal with them all the time anyway.
>
> Apache was kind enough to give us a canned response, "If you have an itch
> scratch it yourself. If it's broke fix it yourself." since we aren't a
> corporate identity we can easily add a disclaimer, "this project is run by
> volunteers. The full Flash api is not supported. The project is open
> source. feel free to jump in and add missing pieces"
>
> on another note, this project could benefit from corporate sponsors and
> endorsements. feature and bug fixing bounties could help bring in the
> freelancer crowd. filling in the missing api would be quickly solved. ...
> if anyone knows how to do this or know someone that does then we need to
> get them on board. ...side tracked again, but I bring this up bc I know
> developers who would help this project along given endorsements,
> sponsorship, branding, etc. in the same way angular is popular even though
> it has so many issues. The main reason it is is because Google endorses it.
> On Apr 19, 2016 10:40 AM, "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.  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 

Re: [Discuss]Accept donation of drawing APIs

[jude]

But Flex is based on the Flash runtime and underlying API. Without the
drawing commands, the interactive layer, point classes, event management,
byte array, birthday data, mouse events, etc Flex and other frameworks
wouldn't be possible.

The Flash layer and related classes are what Flex is built on.

The point of Flex JS is to run on both Flash and the browser so it's not
entirely new. Flash is the foundation for one of those targets. we know
what to expect from it. With Flex js the goal is to build the exact same
house visually and functionally on two aspirate foundations. one is tried
and true and the new one we're still building from the ground up. But for
this to work those two foundations need to be identical IMHO.

I wouldn't be opposed to having Apache Flex projects using external
libraries from Github. But in some capacity we would need the same quality
control, testing and licensing. I don't know if you can do that with an
external library.

I wouldn't worry about expectations and that shouldn't be an excuse. We
deal with them all the time anyway.

Apache was kind enough to give us a canned response, "If you have an itch
scratch it yourself. If it's broke fix it yourself." since we aren't a
corporate identity we can easily add a disclaimer, "this project is run by
volunteers. The full Flash api is not supported. The project is open
source. feel free to jump in and add missing pieces"

on another note, this project could benefit from corporate sponsors and
endorsements. feature and bug fixing bounties could help bring in the
freelancer crowd. filling in the missing api would be quickly solved. ...
if anyone knows how to do this or know someone that does then we need to
get them on board. ...side tracked again, but I bring this up bc I know
developers who would help this project along given endorsements,
sponsorship, branding, etc. in the same way angular is popular even though
it has so many issues. The main reason it is is because Google endorses it.
On Apr 19, 2016 10:40 AM, "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.  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 

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

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

Re: [Discuss]Accept donation of drawing APIs

[Harbs]

webgl is not a very good name, because a lot of the code is actually canvas 
rather than webgl.

I think that expectations can be set using documentation. We can label flash 
packages as “experimental” or something similar, so clients would be aware that 
it will likely be incomplete.

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.

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.

The legal concerns of using the flash package name seems really far-fetched to 
me.

On Apr 19, 2016, at 8:56 AM, Alex Harui  wrote:

> Warning:  I can't decide if I'm just playing devil's advocate or am truly
> concerned about this, but below are some worst-case scenarios, which may
> need to be taken with a grain of salt.
> 
> My latest proposal is that we rename packages from "flash.* to "webgl.*"
> and teach the compiler how to map things.  And maybe also update the
> reflection library to be aware that there was a mapping.  We might end up
> having the compiler do this sort of thing to migrate Flex code bases as
> well.  Yes, it may mean that migration isn't automatic.  But IMO, until we
> find a clean way to do weak references in JS, there is going to have to be
> some migration pain.
> 
> On 4/18/16, 6:47 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
>  wrote:
>> 
>> We already have package names like jquery.*.* and createjs.*.* where we
>> are
>> using the same package names for consistency.  Are we proposing to change
>> all those package names as well, so that we dont set expectations of doing
>> everything that jquery does?
> 
> The jquery and createjs implementations actually use Jquery and CreateJS
> on the JS side, so it should meet expectations.
> 
> There is a potential outcome where we end up having more demand for Flash
> emulation in JS than Flex.  Or spending more time on Starling than on
> Flex.  If that's where the community wants to go, I can't stop it, but
> this project is called Flex.  And, IMO, the big money is in enterprise
> code bases in Flex.
> 
>> 
>> If it turns out that that lot of folks complain about the classes not
>> meeting the expectations, we could probably add the features or worst case
>> swap the package names to flex.*
> 
> We can change the package names and have the compiler do-the-right thing.
> If we set the precedence of using "flash" it will be harder to change in
> the future.  We'll get backwards compatibility complaints and the search
> engines will turn up "flash" stuff for a long time.  When I think about
> the person-hours devoted to Flash at Adobe, it is hard to imagine this
> community finding the time to even do a fraction of that investment.  It
> seemed like even Google was having trouble making Pepper Flash a true
> equivalent.
> 
> And there might be increased legal issues due to things like this [1].
> 
> -Alex
> 
> [1] http://blog.smartbear.com/apis/api-copyright-and-why-you-should-care/
> 
> 
> 

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

Warning:  I can't decide if I'm just playing devil's advocate or am truly
concerned about this, but below are some worst-case scenarios, which may
need to be taken with a grain of salt.

My latest proposal is that we rename packages from "flash.* to "webgl.*"
and teach the compiler how to map things.  And maybe also update the
reflection library to be aware that there was a mapping.  We might end up
having the compiler do this sort of thing to migrate Flex code bases as
well.  Yes, it may mean that migration isn't automatic.  But IMO, until we
find a clean way to do weak references in JS, there is going to have to be
some migration pain.

On 4/18/16, 6:47 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
 wrote:
>
>We already have package names like jquery.*.* and createjs.*.* where we
>are
>using the same package names for consistency.  Are we proposing to change
>all those package names as well, so that we dont set expectations of doing
>everything that jquery does?

The jquery and createjs implementations actually use Jquery and CreateJS
on the JS side, so it should meet expectations.

There is a potential outcome where we end up having more demand for Flash
emulation in JS than Flex.  Or spending more time on Starling than on
Flex.  If that's where the community wants to go, I can't stop it, but
this project is called Flex.  And, IMO, the big money is in enterprise
code bases in Flex.

>
>If it turns out that that lot of folks complain about the classes not
>meeting the expectations, we could probably add the features or worst case
>swap the package names to flex.*

We can change the package names and have the compiler do-the-right thing.
If we set the precedence of using "flash" it will be harder to change in
the future.  We'll get backwards compatibility complaints and the search
engines will turn up "flash" stuff for a long time.  When I think about
the person-hours devoted to Flash at Adobe, it is hard to imagine this
community finding the time to even do a fraction of that investment.  It
seemed like even Google was having trouble making Pepper Flash a true
equivalent.

And there might be increased legal issues due to things like this [1].

-Alex

[1] http://blog.smartbear.com/apis/api-copyright-and-why-you-should-care/

Re: [Discuss]Accept donation of drawing APIs

[OmPrakash Muppirala]

I vote for keeping the package names same, i.e. flash.*.*  The proposed
package name swapping seems to confusing.  And could be error-prone.

We already have package names like jquery.*.* and createjs.*.* where we are
using the same package names for consistency.  Are we proposing to change
all those package names as well, so that we dont set expectations of doing
everything that jquery does?

If it turns out that that lot of folks complain about the classes not
meeting the expectations, we could probably add the features or worst case
swap the package names to flex.*

Thanks,
Om

On Mon, Apr 18, 2016 at 6:10 PM, lizhi  wrote:

> no need some fork.no need extends,it just the final.
>
> now the code and get a.swf and a.js from one code.
>
> and can get starling.js.
>
> if chang the package name.
>
> we can not get a.swf,and starling.js
>
>
>
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52486.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [Discuss]Accept donation of drawing APIs

[lizhi]

no need some fork.no need extends,it just the final.

now the code and get a.swf and a.js from one code.

and can get starling.js.

if chang the package name.

we can not get a.swf,and starling.js



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52486.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [Discuss]Accept donation of drawing APIs

[Mark Kessler]

everytime I read "flex-extras", my brain thinks Flextras instead lol.

-Mark


On Mon, Apr 18, 2016 at 6:44 PM, Harbs  wrote:

> FWIW, I created this organization some time back:
> https://github.com/flex-extras
>
> The idea was to have a place to put code that does not strictly belong on
> ASF repos.
>
> Harbs
>
>

Re: [Discuss]Accept donation of drawing APIs

[Harbs]

FWIW, I created this organization some time back: https://github.com/flex-extras

The idea was to have a place to put code that does not strictly belong on ASF 
repos.

Harbs

On Apr 19, 2016, at 1:16 AM, Alex Harui  wrote:

> 
> 
> On 4/18/16, 3:04 PM, "jude"  wrote:
> 
>> 
>> So the components Tink donated years ago IIRC weren't completely finished
>> (from what I read at the time they were still in progress) or that he may
>> not even be part of the community anymore to maintain it. I still would
>> have liked to have his and others work integrated into a sub swc whether
>> they completely fit or not. Plus it's important to remember that people
>> move on, change jobs, change careers whatever.
> 
> If Tink committed code to an ASF repo, then you and other interested
> committers can finish it.
> 
>> 
>> Alex wrote:
>>> So to be more clear, I am interested in collecting things related to
>>> Flex
>> that the community wants to maintain and improve.  AS3Commons, SWIZ,
>> Parsley, and all of those other 3rd party things that lots of folks use
>> and are afraid the server that serves them might go away.  But only if we
>> have folks here willing to help maintain and create releases for that
>> code, which is why there will be votes on each one.
>> 
>> I agree. I can't tell you how many sites are down that used to host Flash
>> and Flex code (all because of bad marketing Flash muckraking). But even if
>> the projects are dead the least we could do is provide a graveyard here so
>> if we ever need to dig up their rotting corpses we can do so
> 
> IMO, taking in code requires a certain amount of energy for vetting and
> releasing.  ASF repos are not supposed to be a dumping ground.  There
> is/was something called Apache Extras.  I personally don't want to get
> distracted researching it, but if you and others interested want to look
> into it, that may be the right place, or maybe some volunteer simply needs
> to set up a space on GitHub for "lost" code.
> 
> -Alex
> 

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

On 4/18/16, 2:29 PM, "jude"  wrote:

>If the only reason to not use the flash namespace is because it has a
>pejorative term to some ignorant media types and competing web developers
>than that's not a good case.

For me, it is about expectations.  If you claim to have a
flash.display.Sprite, folks will keep bugging you until it does everything
Flash does.  I'd rather set expectations lower and exceed them, but that's
just my opinion.

>
>But if you change it, you're creating problems later when someone wants to
>use to use things like getDefinitionByName("flash.*.*");

That's a good point, but can also be solved in various ways.

>
>Maybe it looks solvable from your end. I'll leave that up to you. But if
>you leave it as is then, you also have the possibility of taking existing
>flash code examples found online, use the same code and get the same
>results without changing the names.

That would be the goal even if we rename the classes, but again, you can
see how that sets us up for folks wanting us to emulate the entire Flash
Player in the browser.  I'm not sure that is what Apache Flex should
really be about.  That may be another community.  IMO, it will be much
less energy to emulate Flex than Flash.  For starters, Flex does not
really promise a timeline and elastic racetrack.

-Alex

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

On 4/18/16, 3:04 PM, "jude"  wrote:

>
>So the components Tink donated years ago IIRC weren't completely finished
>(from what I read at the time they were still in progress) or that he may
>not even be part of the community anymore to maintain it. I still would
>have liked to have his and others work integrated into a sub swc whether
>they completely fit or not. Plus it's important to remember that people
>move on, change jobs, change careers whatever.

If Tink committed code to an ASF repo, then you and other interested
committers can finish it.

>
>Alex wrote:
>> So to be more clear, I am interested in collecting things related to
>>Flex
>that the community wants to maintain and improve.  AS3Commons, SWIZ,
>Parsley, and all of those other 3rd party things that lots of folks use
>and are afraid the server that serves them might go away.  But only if we
>have folks here willing to help maintain and create releases for that
>code, which is why there will be votes on each one.
>
>I agree. I can't tell you how many sites are down that used to host Flash
>and Flex code (all because of bad marketing Flash muckraking). But even if
>the projects are dead the least we could do is provide a graveyard here so
>if we ever need to dig up their rotting corpses we can do so

IMO, taking in code requires a certain amount of energy for vetting and
releasing.  ASF repos are not supposed to be a dumping ground.  There
is/was something called Apache Extras.  I personally don't want to get
distracted researching it, but if you and others interested want to look
into it, that may be the right place, or maybe some volunteer simply needs
to set up a space on GitHub for "lost" code.

-Alex

Re: [Discuss]Accept donation of drawing APIs

[jude]

If the only reason to not use the flash namespace is because it has a
pejorative term to some ignorant media types and competing web developers
than that's not a good case.

If someone doesn't want to use FlexJS because they see the term "flash"
somewhere then they can go find another tool.

But if you change it, you're creating problems later when someone wants to
use to use things like getDefinitionByName("flash.*.*");

Maybe it looks solvable from your end. I'll leave that up to you. But if
you leave it as is then, you also have the possibility of taking existing
flash code examples found online, use the same code and get the same
results without changing the names.

What about if we have both? We have a flash.*.* and the compiler clones the
same classes but under flex.*.*. You could use either and it'd be backward
compatible.

On Mon, Apr 18, 2016 at 1:24 PM, Harbs  wrote:

> My point is that if someone is using a swf-first workflow, they can’t just
> use flex.* packages.
>
> If we do some magic depending on whether it’s JS or AS, that might work.
>
> On Apr 18, 2016, at 9:17 PM, Alex Harui  wrote:
>
> >
> >
> > On 4/18/16, 11:01 AM, "Harbs"  wrote:
> >
> >>
> >> On Apr 18, 2016, at 6:44 PM, Alex Harui  wrote:
> >>
> >>>
> >>>
> >>> On 4/18/16, 6:24 AM, "Harbs"  wrote:
> 
>  2. Assuming we accept it, what should the package naming be? I think
>  there’s a strong case for leaving it as-is.
> >>>
> >>> IMO, I would rename "flash" to "flex".  I'd like our FlexJS code to not
> >>> mention Flash at all, regardless of whether there is some
> >>> legal/copyright
> >>> issue.  It just helps make it clear that this stuff doesn't really use
> >>> Flash, it helps us get out of the expectation that this code will
> >>> somehow
> >>> perfectly replicate what Flash does, and it helps users migrating to
> see
> >>> what flash dependencies they have in their code.
> >>>
> >>> IMO, it isn't that hard to replace flash.*.* with flex.*.*, and I've
> >>> been
> >>> pondering a compile flag that automatically looks for a flex.*.* when
> it
> >>> sees flash.*.*.
> >>
> >> Lizhi siad there’s a problem with changing the package so it can run
> >> Starling.
> >>
> >> I’m not 100% sure what this means, but my understanding is that changing
> >> the package names would require a lot of code changes to redirect to the
> >> Flash packages in playerglobal.swc.
> >> So, for example:
> >> public class TextField extends InteractiveObject
> >> {
> >> }
> >
> > Maybe I have to go look at his code. My assumption is that he has a class
> > called flash.text.TextField that emulates the Flash TextField in WebGL.
> I
> > think we should rename that class to flex.text.TextField in our code
> base.
> >
> > Folks who are migrating code that references flash.text.TextField would
> > have a choice.  One is to manually change the "import
> > flash.text.TextField" at the top of each file that uses it.  That way
> they
> > see which flash classes they are depending on that may not be fully
> > implemented yet.  Or we'll add a compiler flag so that every "import
> > flash.text.TextField" causes the compiler to think you've written
> > "flex.text.TextField" instead.
> >
> >> would have to become:
> >> COMPILE::AS3{
> >> public class TextField extends flash.text.TextField
> >> {
> >> }
> >> }
> >> COMPILE::JS{
> >> public class TextField extends InteractiveObject
> >> {
> >> …
> >> }
> >> }
> >>
> >> I’m not sure if just making all the AS3 classes extend the Flash ones is
> >> enough.
> >
> > I'm not sure I understand which classes you are talking about here.
> >
> >>
> >>>
> 
>  3. How should it be structured in the source? Should all the code go
>  into
>  a single “Flash” project? Should it be split into multiple projects
>  (possibly one for each of the flash top-level packages)?
> >>>
> >>> I haven't looked at the code, but if it is essentially the
> >>> implementation
> >>> behind playerglobal.swc, so it would be one SWC project in
> >>> flex-asjs/frameworks/projects.
> >>
> >> Is there a performance/code size concern with putting everything in a
> >> single SWC? Am I correct in assuming only the necessary code will be
> >> compiled into JS/SWF?
> >
> > I expect that most apps are going to pull in a lot of this code anyway,
> > but yes, only classes needed are included in the output.
> >
> > -Alex
>
>

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

On 4/18/16, 11:01 AM, "Harbs"  wrote:

>
>On Apr 18, 2016, at 6:44 PM, Alex Harui  wrote:
>
>> 
>> 
>> On 4/18/16, 6:24 AM, "Harbs"  wrote:
>>> 
>>> 2. Assuming we accept it, what should the package naming be? I think
>>> there’s a strong case for leaving it as-is.
>> 
>> IMO, I would rename "flash" to "flex".  I'd like our FlexJS code to not
>> mention Flash at all, regardless of whether there is some
>>legal/copyright
>> issue.  It just helps make it clear that this stuff doesn't really use
>> Flash, it helps us get out of the expectation that this code will
>>somehow
>> perfectly replicate what Flash does, and it helps users migrating to see
>> what flash dependencies they have in their code.
>> 
>> IMO, it isn't that hard to replace flash.*.* with flex.*.*, and I've
>>been
>> pondering a compile flag that automatically looks for a flex.*.* when it
>> sees flash.*.*.
>
>Lizhi siad there’s a problem with changing the package so it can run
>Starling.
>
>I’m not 100% sure what this means, but my understanding is that changing
>the package names would require a lot of code changes to redirect to the
>Flash packages in playerglobal.swc.
>So, for example:
>public class TextField extends InteractiveObject
>{
>}

Maybe I have to go look at his code. My assumption is that he has a class
called flash.text.TextField that emulates the Flash TextField in WebGL.  I
think we should rename that class to flex.text.TextField in our code base.

Folks who are migrating code that references flash.text.TextField would
have a choice.  One is to manually change the "import
flash.text.TextField" at the top of each file that uses it.  That way they
see which flash classes they are depending on that may not be fully
implemented yet.  Or we'll add a compiler flag so that every "import
flash.text.TextField" causes the compiler to think you've written
"flex.text.TextField" instead.

>would have to become:
>COMPILE::AS3{
>public class TextField extends flash.text.TextField
>{
>}
>}
>COMPILE::JS{
>public class TextField extends InteractiveObject
>{
>…
>}
>}
>
>I’m not sure if just making all the AS3 classes extend the Flash ones is
>enough.

I'm not sure I understand which classes you are talking about here.

>
>> 
>>> 
>>> 3. How should it be structured in the source? Should all the code go
>>>into
>>> a single “Flash” project? Should it be split into multiple projects
>>> (possibly one for each of the flash top-level packages)?
>> 
>> I haven't looked at the code, but if it is essentially the
>>implementation
>> behind playerglobal.swc, so it would be one SWC project in
>> flex-asjs/frameworks/projects.
>
>Is there a performance/code size concern with putting everything in a
>single SWC? Am I correct in assuming only the necessary code will be
>compiled into JS/SWF?

I expect that most apps are going to pull in a lot of this code anyway,
but yes, only classes needed are included in the output.

-Alex

Re: [Discuss]Accept donation of drawing APIs

[Harbs]

On Apr 18, 2016, at 6:44 PM, Alex Harui  wrote:

> 
> 
> On 4/18/16, 6:24 AM, "Harbs"  wrote:
>> 
>> 2. Assuming we accept it, what should the package naming be? I think
>> there’s a strong case for leaving it as-is.
> 
> IMO, I would rename "flash" to "flex".  I'd like our FlexJS code to not
> mention Flash at all, regardless of whether there is some legal/copyright
> issue.  It just helps make it clear that this stuff doesn't really use
> Flash, it helps us get out of the expectation that this code will somehow
> perfectly replicate what Flash does, and it helps users migrating to see
> what flash dependencies they have in their code.
> 
> IMO, it isn't that hard to replace flash.*.* with flex.*.*, and I've been
> pondering a compile flag that automatically looks for a flex.*.* when it
> sees flash.*.*.

Lizhi siad there’s a problem with changing the package so it can run Starling.

I’m not 100% sure what this means, but my understanding is that changing the 
package names would require a lot of code changes to redirect to the Flash 
packages in playerglobal.swc.
So, for example:
public class TextField extends InteractiveObject
{
}
would have to become:
COMPILE::AS3{
public class TextField extends flash.text.TextField
{
}
}
COMPILE::JS{
public class TextField extends InteractiveObject
{
…
}
}

I’m not sure if just making all the AS3 classes extend the Flash ones is enough.

> 
>> 
>> 3. How should it be structured in the source? Should all the code go into
>> a single “Flash” project? Should it be split into multiple projects
>> (possibly one for each of the flash top-level packages)?
> 
> I haven't looked at the code, but if it is essentially the implementation
> behind playerglobal.swc, so it would be one SWC project in
> flex-asjs/frameworks/projects.

Is there a performance/code size concern with putting everything in a single 
SWC? Am I correct in assuming only the necessary code will be compiled into 
JS/SWF?
> 
> -Alex
> 

Re: [Discuss]Accept donation of drawing APIs

[OmPrakash Muppirala]

Jude,

First off, I am truly sorry that you had a bad experience at Apache Flex,
especially when you were trying to do good to the community by donating
something that you had put your heart and soul into.

We are all learning here.  Instead of saying let's not do this at all,
perhaps you can propose a better way of doing things.   Where we don't look
like dicks, at the same time we make sure that
A. The code being donated is good in legal aspects.
B. The code being donated is something that the community needs/wants
C. The code being donated is not just getting dumped because no one else
wants to deal with it.

You are in the system now.  Be the change you want to see in the world.

Thanks,
Om
On Apr 18, 2016 4:35 AM, "jude"  wrote:

> Slightly off topic, but if someone is kind enough to give you a gift, the
> proper response is to say thank you and accept it. What you do after you
> accept it is another story.
>
> The Apache process of discussing if we should accept said gift is kind of a
> dick move. No offence, but IMHO this behaviour has to stop. And this is not
> directed at you Harbs or anyone in particular.
>
> I'm not saying we don't need to vet a donation, or decide if it should go
> into core or be setup as a side project. But if someone wants to donate
> code they own or built and it's legal then accept it and move on.
>
> People, and myself thought that Apache Flex was going to be the place where
> we make Flash and Flex thrive again. I thought we'd have plenty of donated
> components and projects but you hear someone offer to donate something and
> then it seems to die and you don't hear from them again.
>
> It's a huge turn off to work on a project, want to donate it and then hear
> your  community start talking about if they should accept your donation or
> not. That's not progress is suppression.
>
> IIRC Alex once said he's interested in collecting everything related to
> Flex (and the Flash Platform?) here. So am I. And that's good enough for
> me.
>
> From my perspective, Apache has some anti social processes and procedures
> in practice. But the guidelines say quite clearly that a community can run
> itself how it seems fit. So, something needs to change in my opinion.
> Sorry, if I'm ranting.
>
> Anyway, I want to include lihzi's code and keep the package name the same
> for the reasons Harbs mentioned and if any future projects are cross
> compiled we avoid problems by that as well.
>
> I also suggest we adopt a process to accept license compatible platform
> related future donations automatically and let our discussions focus on
> whether they should be in core or in a secondary location.
> On Apr 17, 2016 6:06 AM, "Harbs"  wrote:
>
> > Lizhi has put together some impressive classes to implement the Flash
> > drawing APIs for FlexJS using Canvas.[1]
> >
> > Lizhi has offered to donate the code[2] and I believe has just filed an
> > ICLA.
> >
> > The question now remains whether we want to include the code. I
> personally
> > see a lot of value in the code as it offers a lot of functionality users
> > are used to out of the box using the same APIs.
> >
> > I do have some questions about accepting the code:
> > 1. Whether to keep the packages as they are. Currently, they use the
> > flash.* packages to match the ones in playerglobal. One the one hand,
> this
> > makes a lot of sense in terms of migrating code because everything stays
> > exactly the same. On the other hand, the package names are misleading as
> > it’s not “Flash” packages. The alternate would be to wrap things in
> apache
> > flex packages, but that would add a lot of work in terms of conditional
> > compilation and redirection. I also don’t know if there are legal issues
> > with using the “flash” package. I can’t imagine what they might be, but
> > INOL…
> >
> > 2. How should these files be organized in FlexJS? This might be related
> to
> > the package names, but might not. I assume this is not “core”. Should it
> > all go into a single project, or should it be split up into multiple
> > projects?
> >
> > Harbs
> >
> > [1]https://github.com/matrix3d/spriteflexjs
> > [2]http://mail-archives.apache.org/mod_mbox/flex-dev/201604.mbox/browser
>

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

On 4/18/16, 6:24 AM, "Harbs"  wrote:
>
>2. Assuming we accept it, what should the package naming be? I think
>there’s a strong case for leaving it as-is.

IMO, I would rename "flash" to "flex".  I'd like our FlexJS code to not
mention Flash at all, regardless of whether there is some legal/copyright
issue.  It just helps make it clear that this stuff doesn't really use
Flash, it helps us get out of the expectation that this code will somehow
perfectly replicate what Flash does, and it helps users migrating to see
what flash dependencies they have in their code.

IMO, it isn't that hard to replace flash.*.* with flex.*.*, and I've been
pondering a compile flag that automatically looks for a flex.*.* when it
sees flash.*.*.


>
>3. How should it be structured in the source? Should all the code go into
>a single “Flash” project? Should it be split into multiple projects
>(possibly one for each of the flash top-level packages)?

I haven't looked at the code, but if it is essentially the implementation
behind playerglobal.swc, so it would be one SWC project in
flex-asjs/frameworks/projects.

-Alex

Re: [Discuss]Accept donation of drawing APIs

[Alex Harui]

On 4/18/16, 4:34 AM, "jude"  wrote:

>Slightly off topic, but if someone is kind enough to give you a gift, the
>proper response is to say thank you and accept it. What you do after you
>accept it is another story.
>
>The Apache process of discussing if we should accept said gift is kind of
>a
>dick move. No offence, but IMHO this behaviour has to stop. And this is
>not
>directed at you Harbs or anyone in particular.
>
>I'm not saying we don't need to vet a donation, or decide if it should go
>into core or be setup as a side project. But if someone wants to donate
>code they own or built and it's legal then accept it and move on.
>
>People, and myself thought that Apache Flex was going to be the place
>where
>we make Flash and Flex thrive again. I thought we'd have plenty of donated
>components and projects but you hear someone offer to donate something and
>then it seems to die and you don't hear from them again.
>
>It's a huge turn off to work on a project, want to donate it and then hear
>your  community start talking about if they should accept your donation or
>not. That's not progress is suppression.

I understand that it can seem wrong to discuss accepting a gift, but
besides the legal vetting others have responded about, Apache is primarily
about communities, and we want to make sure that there are actually folks
interested in maintaining any new code donation.  To me, that is really
what the vote to accept is about.  Those voting +1 are hopefully saying
that they are willing to learn how to fix bugs or add features in that
code.

>
>IIRC Alex once said he's interested in collecting everything related to
>Flex (and the Flash Platform?) here. So am I. And that's good enough for
>me.

So to be more clear, I am interested in collecting things related to Flex
that the community wants to maintain and improve.  AS3Commons, SWIZ,
Parsley, and all of those other 3rd party things that lots of folks use
and are afraid the server that serves them might go away.  But only if we
have folks here willing to help maintain and create releases for that
code, which is why there will be votes on each one.

But I also want to make sure that there is an ecosystem for which active
code bases can find their own communities or folks can maintain a profit
model.  That's another reason for the discussion, which is to make sure
the donators truly understand the impact of donating to Apache.  We are,
in most cases, taking more than code: we are taking in people with that
code.

-Alex

Re: [Discuss]Accept donation of drawing APIs

[Justin Mclean]

Hi,

> Slightly off topic, but if someone is kind enough to give you a gift, the
> proper response is to say thank you and accept it.

We’re willing to accept it, but as part of our PMC responibilities we do need 
to know about it’s contents. I’m sure you know about he story of the Trojan 
horse.:-) I assume that’s not the case here and there’s certainly no assumption 
of ill will and we do welcome all donations. However we do make sure where the 
code province is. It’s a simple question with a simple answer, we get an answer 
and tick that box, and move on, and these's no issues.

> The Apache process of discussing if we should accept said gift is kind of a 
> dick move.

Sorry no I disagree with that. Its our responsibility as PMC members to discuss 
any donation.We should certailly do it with consideration and empathy. We can 
help people though the donation process and point out things that may be issues 
and how to solve them / work around them if needed.

> From my perspective, Apache has some anti social processes and procedures in 
> practice.

IMO far from it, we have checks in place to ensure that the wider community can 
use any donated code without fear of legal or any other issues.

> I also suggest we adopt a process to accept license compatible platform
> related future donations automatically

If it’s comparable sure no issues, but currently in this case we not entirely 
sure is the case. It’s likely to be, but we need a bit more information to be 
sure.

Thanks,
Justin

Re: [Discuss]Accept donation of drawing APIs

[Harbs]

While I can understand Jude’s frustration, I do think it’s clear that we need 
to properly vet donations.

I’d like to try to bring this discussion back on-topic.

I would like to see Lizhi’s code accepted. I think it’s really useful. If not 
actual “core”, it’s pretty close to it.

So the questions remain:
1. Does anyone have objections?

Lizhi, Justin raised the question whether the code originated with you, or did 
some of the code come from some other source? Can you confirm? If some came 
from another source, can you tell us where?

2. Assuming we accept it, what should the package naming be? I think there’s a 
strong case for leaving it as-is.

3. How should it be structured in the source? Should all the code go into a 
single “Flash” project? Should it be split into multiple projects (possibly one 
for each of the flash top-level packages)?

4. Lizhi, are you able and willing to help prepare the code for Apache 
(including adding Apache headers, etc.)?

Thanks,
Harbs

RE: [Non-DoD Source] Re: [Discuss]Accept donation of drawing APIs

[Kessler CTR Mark J]

We should never just accept anything automatically.  Apache is a business 
that has to meet legal requirements.  The PMC for each project are entrusted to 
help protect the organization while looking out for the best interest for their 
project.  While in a perfect world we could just absorb everything in/on/around 
what we work on and sift through it later.   However that brings up several 
issues, which is why we start out with a discussion.  All these things take 
time.

Things like the following should be a general way of looking at things.

1.  Is there a benefit to adding item X to the project?

2.  Does the project / community show an actual interest in using item X?

3.  What type of license does item X have and is it compatible with our own 
licenses?

4.  Are there any developers / committers that need to sign an ICLA before 
donation can happen?

5.  In what repository will it go and where in its structure?

6.  Who will volunteer to scrub / make it compliant with Apache rules and 
licenses.?



-Mark

Re: [Discuss]Accept donation of drawing APIs

[jude]

Slightly off topic, but if someone is kind enough to give you a gift, the
proper response is to say thank you and accept it. What you do after you
accept it is another story.

The Apache process of discussing if we should accept said gift is kind of a
dick move. No offence, but IMHO this behaviour has to stop. And this is not
directed at you Harbs or anyone in particular.

I'm not saying we don't need to vet a donation, or decide if it should go
into core or be setup as a side project. But if someone wants to donate
code they own or built and it's legal then accept it and move on.

People, and myself thought that Apache Flex was going to be the place where
we make Flash and Flex thrive again. I thought we'd have plenty of donated
components and projects but you hear someone offer to donate something and
then it seems to die and you don't hear from them again.

It's a huge turn off to work on a project, want to donate it and then hear
your  community start talking about if they should accept your donation or
not. That's not progress is suppression.

IIRC Alex once said he's interested in collecting everything related to
Flex (and the Flash Platform?) here. So am I. And that's good enough for
me.

>From my perspective, Apache has some anti social processes and procedures
in practice. But the guidelines say quite clearly that a community can run
itself how it seems fit. So, something needs to change in my opinion.
Sorry, if I'm ranting.

Anyway, I want to include lihzi's code and keep the package name the same
for the reasons Harbs mentioned and if any future projects are cross
compiled we avoid problems by that as well.

I also suggest we adopt a process to accept license compatible platform
related future donations automatically and let our discussions focus on
whether they should be in core or in a secondary location.
On Apr 17, 2016 6:06 AM, "Harbs"  wrote:

> Lizhi has put together some impressive classes to implement the Flash
> drawing APIs for FlexJS using Canvas.[1]
>
> Lizhi has offered to donate the code[2] and I believe has just filed an
> ICLA.
>
> The question now remains whether we want to include the code. I personally
> see a lot of value in the code as it offers a lot of functionality users
> are used to out of the box using the same APIs.
>
> I do have some questions about accepting the code:
> 1. Whether to keep the packages as they are. Currently, they use the
> flash.* packages to match the ones in playerglobal. One the one hand, this
> makes a lot of sense in terms of migrating code because everything stays
> exactly the same. On the other hand, the package names are misleading as
> it’s not “Flash” packages. The alternate would be to wrap things in apache
> flex packages, but that would add a lot of work in terms of conditional
> compilation and redirection. I also don’t know if there are legal issues
> with using the “flash” package. I can’t imagine what they might be, but
> INOL…
>
> 2. How should these files be organized in FlexJS? This might be related to
> the package names, but might not. I assume this is not “core”. Should it
> all go into a single project, or should it be split up into multiple
> projects?
>
> Harbs
>
> [1]https://github.com/matrix3d/spriteflexjs
> [2]http://mail-archives.apache.org/mod_mbox/flex-dev/201604.mbox/browser

Re: [Discuss]Accept donation of drawing APIs

[lizhi]

2 contributors are one.



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52440.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [Discuss]Accept donation of drawing APIs

[Justin Mclean]

Hi,

I notice 2 contributors on that github project [1] so may be best we get an 
ICLA from the other contributor as well.

I’ve not looked at the repo in detail but I did notice a largish initial 
checkins [2], and there a few other meta tags [3] and the like which might mean 
some of  the code code is from elsewhere and not written from scratch. Did the 
initial code come from shumway or another similar project?

Thanks,
Justin

1. https://github.com/matrix3d/spriteflexjs/graphs/contributors 

2. 
https://github.com/matrix3d/spriteflexjs/commit/7f4265075a354d3c337517747deb552b00adf5da
 

3 
https://github.com/matrix3d/spriteflexjs/blob/1630065643458ec56edde491251653648819c746/src/flash/display3D/Context3DTextureFormat.as
 

Re: [Discuss]Accept donation of drawing APIs

[lizhi]

i think must flash package.
so it can run starling,etc



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52438.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.