Re: WebAssembly Flash ByPass

[Gary Yang]

Thanks, I would love to see how you can get there, W3C started designing
HTML5 in 2009, Firefox is still making exception for Flash Player now,
maybe you can help them get rid of it and unify the web truly.

On Mon, Apr 10, 2017 at 5:24 PM, Jason Taylor  wrote:

> Gary, do you even have any idea what WebAssembly is? You should check out
> some articles on it: https://github.com/WebAssembly/design/blob/
> master/FAQ.md, https://developer.mozilla.org/en-US/docs/WebAssembly/
> Concepts
>
> In a nutshell the browser vendors finally realized that HTML+JS will never
> be efficent enough to implement complex software/games in browser, and thus
> WebAssembly was born. It was designed by the W3C committee that included
> all the major browser vendors.
>
> Please do yourself a favor and research your opinion before you spread
> mis-information.
>
>
>
> -Original Message-
> From: Gary Yang [mailto:flashflex...@gmail.com]
> Sent: Monday, April 10, 2017 2:21 PM
> To: dev@flex.apache.org
> Subject: Re: WebAssembly Flash ByPass
>
> 1) It takes a long time to make a powerful system like Flash Player stable
> enough, Google Map has been using webGL for a long time, improved a lot
> still crash all the time.
> 2) Politically, none of the major browser vendors would let anything our
> of their control grow bigger anymore, Flash Player is the only exception,
> it came too early and too important to the web to be killed.
>
> The only chance to implement high performance application across main
> stream browsers is still Flash with stage3D AGAL, time has proved it, I
> don't the majority get it, when it comes to tech, this is usually it, most
> just follow what others say.
>
> Sad haaa? What if spent time in implementing Flex with AGAL from the very
> beginning? Flash platform might not be on the hanging edge...
>
>
> On Mon, Apr 10, 2017 at 5:16 PM, Josh Tynjala 
> wrote:
>
> > I don't think you can simply compile LightSpark as-is to WebAssembly.
> > I suspect that its rendering code will need serious modification to be
> > able to draw to HTML Canvas or WebGL instead of whatever native APIs
> > it uses now. This part probably wouldn't be trivial.
> >
> > - Josh
> >
> > On Mon, Apr 10, 2017 at 1:52 PM, Jason Taylor  wrote:
> >
> > > Why would we be implementing anything? I'm talking about taking
> > LightSpark
> > > as is (with their 252 open bugs) compiling it to LLVM, using that
> > > input
> > for
> > > the WebAssembly compiler and compiling the output binary as a
> > > LightSpark WebAssembly drop in flash player.  This has nothing to do
> > > with the
> > existing
> > > FlexJS work and is merely to allow the existing flash apps to run in
> > > browser, cross platform without a plug-in (such as Safari on iOS).
>  Not
> > > quite sure what exactly is so crazy here.  Sorry, FlexJS will never
> > > give
> > us
> > > the performance we (Dedoose) need, so extending the life cycle of
> > > the
> > flash
> > > player a couple more years to buy us time for a complete rewrite in
> > > a performant client technology is pretty important to us.
> > > ~ JT
> > >
> > >
> > >
> > > -Original Message-
> > > From: Gary Yang [mailto:flashflex...@gmail.com]
> > > Sent: Monday, April 10, 2017 1:46 PM
> > > To: dev@flex.apache.org
> > > Subject: Re: WebAssembly Flash ByPass
> > >
> > > No mean to be offensive, implementing everything in WebAssembly
> > > feels
> > just
> > > like talking about living in Mars, even with HTML/Javascript/CSS
> > regardless
> > > of performance, after so many years ...
> > >
> > > On Mon, Apr 10, 2017 at 4:18 PM, piotrz 
> > wrote:
> > >
> > > > Hi Gary,
> > > >
> > > > Please be tolerant to Jason's opinion and ideas. Apache Flex is an
> > > > open source project and if Jason would like to bring some idea
> > > > here he is very welcome, same as you.
> > > >
> > > > Piotr
> > > >
> > > >
> > > >
> > > > -
> > > > Apache Flex PMC
> > > > piotrzarzyck...@gmail.com
> > > > --
> > > > View this message in context: http://apache-flex-
> > > > development.247.n4.nabble.com/FlexJS-feature-chart-work-
> > > > status-tp61035p61082.html
> > > > Sent from the Apache Flex Development mailing list archive at
> > Nabble.com.
> > > >
> > >
> >
>

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Justin Mclean]

Hi,

I’ll respond to your email in full later.

Lets assume we make it a bead.

In this case it will add more lines of code (about a dozen) to HTTPService and 
will have a bigger cost people who both use it and don’t use it. Currently it’s 
only a two line method and there no runtime cost to people who don’t use it.

That doesn’t seem PAYG to me. Do you still think that is best way forward? Or 
can you suggest another way to get this to work that is no cost to people who 
don’t use it?

Here's what I think would need to be done. I would need to add something like 
this to the JS send method (or call new method(s) that do something similar).

int noBeads:int = 0;
for (int i = 0; i < noBeads; i++) {
if (beads[i] is CORSAuthenicationBead) {
element.withAuthenication =  (beads[i] as 
CORSAuthenicationBead).withAuthenication;
}
} 

(withAuthenication needs to set at runtime not just when the bead is added)

We could perhaps create a CORSAuthenicationBead and a 
CORSRuntimeAuthenicationBead, but that’s will add more code/cost, as well as 
the code above we would also need to add code in addBead as well to set 
withAuthenication.

 But wait addBead only exist on the AS side not the JS side (unless sI’m 
missing something):
COMPILE::SWF
public function addBead(bead:IBead):void

And this it looks like the set strand method is broken on JS:
 public function set strand(value:IStrand):void
 {
 _strand = value;
 if (_beads == null)
 {
 for each (var bead:IBead in beads)
 addBead(bead);
 }
 
 dispatchEvent(new org.apache.flex.events.Event("beadsAdded"));
}

So we also would need add a JS version of addBead as well with again more code 
and cost.

So I’ll ask again given the above do you think that a bead is best here? 
Especially when it adds runtime cost (runtime and size) to user if they use it 
or not?

Thanks,
Justin

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Alex Harui]

Responding to you and Justin in this post...

On 4/10/17, 1:55 AM, "Greg Dove"  wrote:

>Actually I wasn't sure whether the compiler eliminated the dead js code.
>But we know that it can.
>
>I get the point about the 'swiss-army-knife' but I don't think that
>applies
>here, because I think this is more a 'standard tool'. I can only directly
>recall one Flex project in the last 6 years that did not require the swf
>crossdomain security model. Perhaps I have forgotten some, but I suspect
>that the world is becoming more interconnected, not less. I know there
>will
>definitely be some who don't need this, and I guess there are certain
>types
>of application that always will be single-domain. But unless I
>misunderstand, it sounds like this need might be more for the majority
>than
>the minority.
>
>The point about the GCC stuff though I think is a little contrasting to
>the
>PAYG philosphy elsewhere.

Because AS allows you to write:

   myHttpService["withCredentials"] = true;

Our tools currently add @export to all public APIs.  And thus, the code
Justin added is not eliminated.  I just compiled FlexJSStore and the
string "withCredentials" is in the optimized JS twice.

Certainly, the tools could become smarter, but they aren't now, and we
have a pattern and protocol for adding features, which is to use beads.
And even then, we want the framework to scale to supporting really large
enterprise apps where not all files are compiled at the same time and APIs
are referenced and shared across these compilation sets.  And I don't
really think it is practical to create a tool chain that will ever figure
out what is dead code across compilation sets.  I believe the bead pattern
will be great for optimizing in these development environments.


>
>"AFAIK, public APIs have @export and are kept around.  Which will be a
>good thing
>in multi-module apps some day."
>
>It sounds like we are keeping a lot of code that could be optimized or
>automatically excluded because it will be a good thing "some day" (the day
>when we support module loading). That sounds like the opposite of PAYG to
>me, because many projects may not need 'module loading' (and we don't have
>this yet anyway). I'm just trying to throw a potentially different way of
>looking at this in here, because, in theory at least, the closure compiler
>should be able to make a whole bunch of stuff go away in the release build
>if it is not used (dead code elimination, DCE). In practice, I have not
>tried it with any sizeable codebase, but I know other typedLanguage-toJS
>compilers get the job done here, and I know that things like including
>reflection data or not are also choices included in the options for output
>in at least one other toJS compiler.
>
>If this can work properly then we could actually have our cake and eat it
>too. And yes the future might mean other things for modules, but perhaps
>there are ways to get that working even with the renaming (DCE maybe not
>so
>much, I agree).
>

IMO, we would provide different compiler options for those who can compile
everything at once.  I think what would be required at the simplest level
is some promise from the developer that they did not use any bracket
access (myService["withCredentials"]) in their code, and I suppose that
would mean we couldn't use bracket access in the framework code either
(which I hope we don't do much of, if any.  And maybe we could get smarter
and find bracket access and inform GCC which APIs to void renaming, but
then you couldn't do "string math" in bracket access or use string
variables without code-flow analysis in the compiler.

myService["with" + "Credentials"]

var foo:String = "withCredentials";
myService[foo];

But again, those doing really big apps where they don't compile everything
at once will need some other way to optimize and being able to choose what
beads they want to composite is the best plan I can think of so far.

>On Mon, Apr 10, 2017 at 8:32 PM, Justin Mclean 
>wrote:
>
>> Hi,
>>
>> >  And the net result should be that code you didn't in your app, isn't
>>in
>> your app.
>>
>> As Greg pointed out the compiler can removed unused JS code i.e. methods
>> that are not called. See for instance [1] for details. So in this case
>>if
>> you don’t use it will not end up in the AS code (as it’s JS only) and
>>will
>> not end up in production JS code.

This is not currently true, and probably can't be true for some
development environments.  See my response to Greg above.

>>
>> > So when you break stuff out into a bead, we want the net code size and
>> performance for
>> > someone not using the bead to be the same or better.
>>
>> In this case it is the same, if it was moved to a bead it would be worse
>> for people who needed it. Only by tiny amounts but that’s the point
>>you’re
>> trying to make i.e. slow dead by a 1000 tiny additions, and as you say
>>lots
>> of people will need CORS support.

Yes.  That is what 

RE: WebAssembly Flash ByPass

[Jason Taylor]

Gary, do you even have any idea what WebAssembly is? You should check out some 
articles on it: https://github.com/WebAssembly/design/blob/master/FAQ.md, 
https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

In a nutshell the browser vendors finally realized that HTML+JS will never be 
efficent enough to implement complex software/games in browser, and thus 
WebAssembly was born. It was designed by the W3C committee that included all 
the major browser vendors.   

Please do yourself a favor and research your opinion before you spread 
mis-information.



-Original Message-
From: Gary Yang [mailto:flashflex...@gmail.com] 
Sent: Monday, April 10, 2017 2:21 PM
To: dev@flex.apache.org
Subject: Re: WebAssembly Flash ByPass

1) It takes a long time to make a powerful system like Flash Player stable 
enough, Google Map has been using webGL for a long time, improved a lot still 
crash all the time.
2) Politically, none of the major browser vendors would let anything our of 
their control grow bigger anymore, Flash Player is the only exception, it came 
too early and too important to the web to be killed.

The only chance to implement high performance application across main stream 
browsers is still Flash with stage3D AGAL, time has proved it, I don't the 
majority get it, when it comes to tech, this is usually it, most just follow 
what others say.

Sad haaa? What if spent time in implementing Flex with AGAL from the very 
beginning? Flash platform might not be on the hanging edge...


On Mon, Apr 10, 2017 at 5:16 PM, Josh Tynjala  wrote:

> I don't think you can simply compile LightSpark as-is to WebAssembly. 
> I suspect that its rendering code will need serious modification to be 
> able to draw to HTML Canvas or WebGL instead of whatever native APIs 
> it uses now. This part probably wouldn't be trivial.
>
> - Josh
>
> On Mon, Apr 10, 2017 at 1:52 PM, Jason Taylor  wrote:
>
> > Why would we be implementing anything? I'm talking about taking
> LightSpark
> > as is (with their 252 open bugs) compiling it to LLVM, using that 
> > input
> for
> > the WebAssembly compiler and compiling the output binary as a 
> > LightSpark WebAssembly drop in flash player.  This has nothing to do 
> > with the
> existing
> > FlexJS work and is merely to allow the existing flash apps to run in
> > browser, cross platform without a plug-in (such as Safari on iOS).   Not
> > quite sure what exactly is so crazy here.  Sorry, FlexJS will never 
> > give
> us
> > the performance we (Dedoose) need, so extending the life cycle of 
> > the
> flash
> > player a couple more years to buy us time for a complete rewrite in 
> > a performant client technology is pretty important to us.
> > ~ JT
> >
> >
> >
> > -Original Message-
> > From: Gary Yang [mailto:flashflex...@gmail.com]
> > Sent: Monday, April 10, 2017 1:46 PM
> > To: dev@flex.apache.org
> > Subject: Re: WebAssembly Flash ByPass
> >
> > No mean to be offensive, implementing everything in WebAssembly 
> > feels
> just
> > like talking about living in Mars, even with HTML/Javascript/CSS
> regardless
> > of performance, after so many years ...
> >
> > On Mon, Apr 10, 2017 at 4:18 PM, piotrz 
> wrote:
> >
> > > Hi Gary,
> > >
> > > Please be tolerant to Jason's opinion and ideas. Apache Flex is an 
> > > open source project and if Jason would like to bring some idea 
> > > here he is very welcome, same as you.
> > >
> > > Piotr
> > >
> > >
> > >
> > > -
> > > Apache Flex PMC
> > > piotrzarzyck...@gmail.com
> > > --
> > > View this message in context: http://apache-flex-
> > > development.247.n4.nabble.com/FlexJS-feature-chart-work-
> > > status-tp61035p61082.html
> > > Sent from the Apache Flex Development mailing list archive at
> Nabble.com.
> > >
> >
>

Re: WebAssembly Flash ByPass

[Gary Yang]

1) It takes a long time to make a powerful system like Flash Player stable
enough, Google Map has been using webGL for a long time, improved a lot
still crash all the time.
2) Politically, none of the major browser vendors would let anything our of
their control grow bigger anymore, Flash Player is the only exception, it
came too early and too important to the web to be killed.

The only chance to implement high performance application across main
stream browsers is still Flash with stage3D AGAL, time has proved it, I
don't the majority get it, when it comes to tech, this is usually it, most
just follow what others say.

Sad haaa? What if spent time in implementing Flex with AGAL from the very
beginning? Flash platform might not be on the hanging edge...


On Mon, Apr 10, 2017 at 5:16 PM, Josh Tynjala  wrote:

> I don't think you can simply compile LightSpark as-is to WebAssembly. I
> suspect that its rendering code will need serious modification to be able
> to draw to HTML Canvas or WebGL instead of whatever native APIs it uses
> now. This part probably wouldn't be trivial.
>
> - Josh
>
> On Mon, Apr 10, 2017 at 1:52 PM, Jason Taylor  wrote:
>
> > Why would we be implementing anything? I'm talking about taking
> LightSpark
> > as is (with their 252 open bugs) compiling it to LLVM, using that input
> for
> > the WebAssembly compiler and compiling the output binary as a LightSpark
> > WebAssembly drop in flash player.  This has nothing to do with the
> existing
> > FlexJS work and is merely to allow the existing flash apps to run in
> > browser, cross platform without a plug-in (such as Safari on iOS).   Not
> > quite sure what exactly is so crazy here.  Sorry, FlexJS will never give
> us
> > the performance we (Dedoose) need, so extending the life cycle of the
> flash
> > player a couple more years to buy us time for a complete rewrite in a
> > performant client technology is pretty important to us.
> > ~ JT
> >
> >
> >
> > -Original Message-
> > From: Gary Yang [mailto:flashflex...@gmail.com]
> > Sent: Monday, April 10, 2017 1:46 PM
> > To: dev@flex.apache.org
> > Subject: Re: WebAssembly Flash ByPass
> >
> > No mean to be offensive, implementing everything in WebAssembly feels
> just
> > like talking about living in Mars, even with HTML/Javascript/CSS
> regardless
> > of performance, after so many years ...
> >
> > On Mon, Apr 10, 2017 at 4:18 PM, piotrz 
> wrote:
> >
> > > Hi Gary,
> > >
> > > Please be tolerant to Jason's opinion and ideas. Apache Flex is an
> > > open source project and if Jason would like to bring some idea here he
> > > is very welcome, same as you.
> > >
> > > Piotr
> > >
> > >
> > >
> > > -
> > > Apache Flex PMC
> > > piotrzarzyck...@gmail.com
> > > --
> > > View this message in context: http://apache-flex-
> > > development.247.n4.nabble.com/FlexJS-feature-chart-work-
> > > status-tp61035p61082.html
> > > Sent from the Apache Flex Development mailing list archive at
> Nabble.com.
> > >
> >
>

Re: WebAssembly Flash ByPass

[Josh Tynjala]

I don't think you can simply compile LightSpark as-is to WebAssembly. I
suspect that its rendering code will need serious modification to be able
to draw to HTML Canvas or WebGL instead of whatever native APIs it uses
now. This part probably wouldn't be trivial.

- Josh

On Mon, Apr 10, 2017 at 1:52 PM, Jason Taylor  wrote:

> Why would we be implementing anything? I'm talking about taking LightSpark
> as is (with their 252 open bugs) compiling it to LLVM, using that input for
> the WebAssembly compiler and compiling the output binary as a LightSpark
> WebAssembly drop in flash player.  This has nothing to do with the existing
> FlexJS work and is merely to allow the existing flash apps to run in
> browser, cross platform without a plug-in (such as Safari on iOS).   Not
> quite sure what exactly is so crazy here.  Sorry, FlexJS will never give us
> the performance we (Dedoose) need, so extending the life cycle of the flash
> player a couple more years to buy us time for a complete rewrite in a
> performant client technology is pretty important to us.
> ~ JT
>
>
>
> -Original Message-
> From: Gary Yang [mailto:flashflex...@gmail.com]
> Sent: Monday, April 10, 2017 1:46 PM
> To: dev@flex.apache.org
> Subject: Re: WebAssembly Flash ByPass
>
> No mean to be offensive, implementing everything in WebAssembly feels just
> like talking about living in Mars, even with HTML/Javascript/CSS regardless
> of performance, after so many years ...
>
> On Mon, Apr 10, 2017 at 4:18 PM, piotrz  wrote:
>
> > Hi Gary,
> >
> > Please be tolerant to Jason's opinion and ideas. Apache Flex is an
> > open source project and if Jason would like to bring some idea here he
> > is very welcome, same as you.
> >
> > Piotr
> >
> >
> >
> > -
> > Apache Flex PMC
> > piotrzarzyck...@gmail.com
> > --
> > View this message in context: http://apache-flex-
> > development.247.n4.nabble.com/FlexJS-feature-chart-work-
> > status-tp61035p61082.html
> > Sent from the Apache Flex Development mailing list archive at Nabble.com.
> >
>

Re: WebAssembly Flash ByPass

[Harbs]

I would be very interested in hearing how an experiment like that would work 
out.

> On Apr 10, 2017, at 4:52 PM, Jason Taylor  wrote:
> 
> Why would we be implementing anything? I'm talking about taking LightSpark as 
> is (with their 252 open bugs) compiling it to LLVM, using that input for the 
> WebAssembly compiler and compiling the output binary as a LightSpark 
> WebAssembly drop in flash player.  This has nothing to do with the existing 
> FlexJS work and is merely to allow the existing flash apps to run in browser, 
> cross platform without a plug-in (such as Safari on iOS).   Not quite sure 
> what exactly is so crazy here.  Sorry, FlexJS will never give us the 
> performance we (Dedoose) need, so extending the life cycle of the flash 
> player a couple more years to buy us time for a complete rewrite in a 
> performant client technology is pretty important to us.
> ~ JT
> 
> 
> 
> -Original Message-
> From: Gary Yang [mailto:flashflex...@gmail.com] 
> Sent: Monday, April 10, 2017 1:46 PM
> To: dev@flex.apache.org
> Subject: Re: WebAssembly Flash ByPass
> 
> No mean to be offensive, implementing everything in WebAssembly feels just 
> like talking about living in Mars, even with HTML/Javascript/CSS regardless 
> of performance, after so many years ...
> 
> On Mon, Apr 10, 2017 at 4:18 PM, piotrz  wrote:
> 
>> Hi Gary,
>> 
>> Please be tolerant to Jason's opinion and ideas. Apache Flex is an 
>> open source project and if Jason would like to bring some idea here he 
>> is very welcome, same as you.
>> 
>> Piotr
>> 
>> 
>> 
>> -
>> Apache Flex PMC
>> piotrzarzyck...@gmail.com
>> --
>> View this message in context: http://apache-flex-
>> development.247.n4.nabble.com/FlexJS-feature-chart-work-
>> status-tp61035p61082.html
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>> 

RE: WebAssembly Flash ByPass

[Jason Taylor]

Why would we be implementing anything? I'm talking about taking LightSpark as 
is (with their 252 open bugs) compiling it to LLVM, using that input for the 
WebAssembly compiler and compiling the output binary as a LightSpark 
WebAssembly drop in flash player.  This has nothing to do with the existing 
FlexJS work and is merely to allow the existing flash apps to run in browser, 
cross platform without a plug-in (such as Safari on iOS).   Not quite sure what 
exactly is so crazy here.  Sorry, FlexJS will never give us the performance we 
(Dedoose) need, so extending the life cycle of the flash player a couple more 
years to buy us time for a complete rewrite in a performant client technology 
is pretty important to us.
~ JT



-Original Message-
From: Gary Yang [mailto:flashflex...@gmail.com] 
Sent: Monday, April 10, 2017 1:46 PM
To: dev@flex.apache.org
Subject: Re: WebAssembly Flash ByPass

No mean to be offensive, implementing everything in WebAssembly feels just like 
talking about living in Mars, even with HTML/Javascript/CSS regardless of 
performance, after so many years ...

On Mon, Apr 10, 2017 at 4:18 PM, piotrz  wrote:

> Hi Gary,
>
> Please be tolerant to Jason's opinion and ideas. Apache Flex is an 
> open source project and if Jason would like to bring some idea here he 
> is very welcome, same as you.
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-feature-chart-work-
> status-tp61035p61082.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: WebAssembly Flash ByPass

[Gary Yang]

No mean to be offensive, implementing everything in WebAssembly feels just
like talking about living in Mars, even with HTML/Javascript/CSS regardless
of performance, after so many years ...

On Mon, Apr 10, 2017 at 4:18 PM, piotrz  wrote:

> Hi Gary,
>
> Please be tolerant to Jason's opinion and ideas. Apache Flex is an open
> source project and if Jason would like to bring some idea here he is very
> welcome, same as you.
>
> Piotr
>
>
>
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: http://apache-flex-
> development.247.n4.nabble.com/FlexJS-feature-chart-work-
> status-tp61035p61082.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] feature/chart_work status

[Peter Ent]

Thank you for your patience on this. I did run maven as well on my
directories and got a clean run.

On 4/10/17, 4:29 PM, "Christofer Dutz"  wrote:

>+1 for merging as you say you tested FlexJSStore and it¹s working, we
>might get develop working again, which is a rather desirable thing ;-)
>
>Chris
>
>
>Am 10.04.17, 20:40 schrieb "Peter Ent" :
>
>I now have the feature/chart-work branch in good shape: the frameworks
>projects build and so do all of the examples; both ANT and maven
>builds
>ran. I'm much, much more confident in the changes and stability of
>this
>feature branch than I was last week.
>
>I ran the following examples successfully: ChartExample,
>DataBindingExample, DataGridExample, FlexJSStore, DesktopMap,
>DateChooser,
>MDLExample, and TreeExample. Several of the others need some
>reworking but
>I think they are just layout issues.
>
>The changes in this feature branch reduce the amount of HTML nodes
>created
>and reduce the number of times layouts are invoked upon component
>start-up. I found several cases of redundant events and shifted some
>code
>around to make things more consistent and streamlined.
>
>My next task is to write up a Wiki page on the FlexJS site (or amend
>existing pages, as needed). I will be writing about component
>creation,
>life cycle, and layout development.
>
>I would like to merge feature/chart-work into development tomorrow. I
>do
>not anticipate any further changes unless someone finds issues that
>would
>prevent this.
>
>If there are specific examples or build questions, I'll be happy to
>answer
>them as best I can.
>
>Regards,
>Peter
>
>On 4/10/17, 9:44 AM, "Peter Ent"  wrote:
>
>>I know have MDLExample working.
>>
>>I think I did this unwittingly: The MaterialDesignLite project's
>>default.css has the IDateProviderItemRendererMapper for the Tabs and
>>TabBar components specified as
>TabsItemRendererFactoryForArrayListData.
>>But the dataProvider being supplied to the tab components were
>Arrays and
>>not ArrayLists.
>>
>>I changed the data models to supply ArrayLists for the dataProviders
>and
>>now the tabs are working. I think our changes together made this work
>>again.
>>
>>Perhaps MDL should have a single item renderer data factory that is
>>universal in that it can accept either Array or ArrayList data and
>help
>>prevent this from happening in the future. I set this type of thing
>up in
>>the Express package (which I still have to test, now that I write
>this).
>>
>>This is the feature/chart-work branch.
>>
>>Regards,
>>Peter
>>
>>On 4/9/17, 6:26 PM, "piotrz"  wrote:
>>
>>>Ahh I forgot to mention that you can see issue when you look into
>>>MDLExample.
>>>Main TabBar do not display Tabs.
>>>
>>>Basically in TabBarView itemsCreated method has not been called.
>>>
>>>If you lost in there I will put some basic example.
>>>
>>>Piotr
>>>
>>>
>>>
>>>-
>>>Apache Flex PMC
>>>piotrzarzyck...@gmail.com
>>>--
>>>View this message in context:
>
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>l
>>>e
>
>>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-t
>>>p
>>>6
>
>>>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7
>>>b
>>>1
>
>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmO
>>>D
>>>B
>>>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>>>Sent from the Apache Flex Development mailing list archive at
>Nabble.com.
>>
>
>
>

Re: [FlexJS] feature/chart_work status

[Christofer Dutz]

+1 for merging as you say you tested FlexJSStore and it’s working, we might get 
develop working again, which is a rather desirable thing ;-)

Chris


Am 10.04.17, 20:40 schrieb "Peter Ent" :

I now have the feature/chart-work branch in good shape: the frameworks
projects build and so do all of the examples; both ANT and maven builds
ran. I'm much, much more confident in the changes and stability of this
feature branch than I was last week.

I ran the following examples successfully: ChartExample,
DataBindingExample, DataGridExample, FlexJSStore, DesktopMap, DateChooser,
MDLExample, and TreeExample. Several of the others need some reworking but
I think they are just layout issues.

The changes in this feature branch reduce the amount of HTML nodes created
and reduce the number of times layouts are invoked upon component
start-up. I found several cases of redundant events and shifted some code
around to make things more consistent and streamlined.

My next task is to write up a Wiki page on the FlexJS site (or amend
existing pages, as needed). I will be writing about component creation,
life cycle, and layout development.

I would like to merge feature/chart-work into development tomorrow. I do
not anticipate any further changes unless someone finds issues that would
prevent this.

If there are specific examples or build questions, I'll be happy to answer
them as best I can.

Regards,
Peter

On 4/10/17, 9:44 AM, "Peter Ent"  wrote:

>I know have MDLExample working.
>
>I think I did this unwittingly: The MaterialDesignLite project's
>default.css has the IDateProviderItemRendererMapper for the Tabs and
>TabBar components specified as TabsItemRendererFactoryForArrayListData.
>But the dataProvider being supplied to the tab components were Arrays and
>not ArrayLists. 
>
>I changed the data models to supply ArrayLists for the dataProviders and
>now the tabs are working. I think our changes together made this work
>again.
>
>Perhaps MDL should have a single item renderer data factory that is
>universal in that it can accept either Array or ArrayList data and help
>prevent this from happening in the future. I set this type of thing up in
>the Express package (which I still have to test, now that I write this).
>
>This is the feature/chart-work branch.
>
>Regards,
>Peter
>
>On 4/9/17, 6:26 PM, "piotrz"  wrote:
>
>>Ahh I forgot to mention that you can see issue when you look into
>>MDLExample.
>>Main TabBar do not display Tabs.
>>
>>Basically in TabBarView itemsCreated method has not been called.
>>
>>If you lost in there I will put some basic example.
>>
>>Piotr
>>
>>
>>
>>-
>>Apache Flex PMC
>>piotrzarzyck...@gmail.com
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp
>>6
>>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b
>>1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmOD
>>B
>>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: WebAssembly Flash ByPass

[piotrz]

Hi Gary,

Please be tolerant to Jason's opinion and ideas. Apache Flex is an open
source project and if Jason would like to bring some idea here he is very
welcome, same as you.

Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-feature-chart-work-status-tp61035p61082.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: WebAssembly Flash ByPass

[Jason Taylor]

yes because LLVM to LLVM is so difficult... You have actually have anything 
constructive to contribute?

-Original Message-
From: Gary Yang [mailto:flashflex...@gmail.com] 
Sent: Monday, April 10, 2017 1:09 PM
To: dev@flex.apache.org
Subject: Re: WebAssembly Flash ByPass

Yeah the life in Mars could be very exciting, let me know when you are there ...

On Mon, Apr 10, 2017 at 3:17 PM, Jason Taylor  wrote:

> WebAssembly is officially supported in both Chrome and Firefox right 
> now, and in the rest very soon.
> WebAssembly can take LLVM and compiles to a binary format that works 
> cross browser at near native speeds without any plugin.
> LightSpark is an open source implemention of the flash player written 
> in
> C++ that can compile to LLVM.  Potentionally we can compile LightSpark 
> C++ to
> LLVM and be able to run all flash apps in all browsers without any plugin
> and completely bypass the death of the flash player.   Thoughts?
> ~ JT
>
>

Re: WebAssembly Flash ByPass

[Gary Yang]

Yeah the life in Mars could be very exciting, let me know when you are
there ...

On Mon, Apr 10, 2017 at 3:17 PM, Jason Taylor  wrote:

> WebAssembly is officially supported in both Chrome and Firefox right now,
> and in the rest very soon.
> WebAssembly can take LLVM and compiles to a binary format that works cross
> browser at near native speeds without any plugin.
> LightSpark is an open source implemention of the flash player written in
> C++ that can compile to LLVM.  Potentionally we can compile LightSpark to
> LLVM and be able to run all flash apps in all browsers without any plugin
> and completely bypass the death of the flash player.   Thoughts?
> ~ JT
>
>

WebAssembly Flash ByPass

[Jason Taylor]

WebAssembly is officially supported in both Chrome and Firefox right now, and 
in the rest very soon.
WebAssembly can take LLVM and compiles to a binary format that works cross 
browser at near native speeds without any plugin.
LightSpark is an open source implemention of the flash player written in C++ 
that can compile to LLVM.  Potentionally we can compile LightSpark to LLVM and 
be able to run all flash apps in all browsers without any plugin and completely 
bypass the death of the flash player.   Thoughts?
~ JT

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I now have the feature/chart-work branch in good shape: the frameworks
projects build and so do all of the examples; both ANT and maven builds
ran. I'm much, much more confident in the changes and stability of this
feature branch than I was last week.

I ran the following examples successfully: ChartExample,
DataBindingExample, DataGridExample, FlexJSStore, DesktopMap, DateChooser,
MDLExample, and TreeExample. Several of the others need some reworking but
I think they are just layout issues.

The changes in this feature branch reduce the amount of HTML nodes created
and reduce the number of times layouts are invoked upon component
start-up. I found several cases of redundant events and shifted some code
around to make things more consistent and streamlined.

My next task is to write up a Wiki page on the FlexJS site (or amend
existing pages, as needed). I will be writing about component creation,
life cycle, and layout development.

I would like to merge feature/chart-work into development tomorrow. I do
not anticipate any further changes unless someone finds issues that would
prevent this.

If there are specific examples or build questions, I'll be happy to answer
them as best I can.

Regards,
Peter

On 4/10/17, 9:44 AM, "Peter Ent"  wrote:

>I know have MDLExample working.
>
>I think I did this unwittingly: The MaterialDesignLite project's
>default.css has the IDateProviderItemRendererMapper for the Tabs and
>TabBar components specified as TabsItemRendererFactoryForArrayListData.
>But the dataProvider being supplied to the tab components were Arrays and
>not ArrayLists. 
>
>I changed the data models to supply ArrayLists for the dataProviders and
>now the tabs are working. I think our changes together made this work
>again.
>
>Perhaps MDL should have a single item renderer data factory that is
>universal in that it can accept either Array or ArrayList data and help
>prevent this from happening in the future. I set this type of thing up in
>the Express package (which I still have to test, now that I write this).
>
>This is the feature/chart-work branch.
>
>Regards,
>Peter
>
>On 4/9/17, 6:26 PM, "piotrz"  wrote:
>
>>Ahh I forgot to mention that you can see issue when you look into
>>MDLExample.
>>Main TabBar do not display Tabs.
>>
>>Basically in TabBarView itemsCreated method has not been called.
>>
>>If you lost in there I will put some basic example.
>>
>>Piotr
>>
>>
>>
>>-
>>Apache Flex PMC
>>piotrzarzyck...@gmail.com
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp
>>6
>>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b
>>1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmOD
>>B
>>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I know have MDLExample working.

I think I did this unwittingly: The MaterialDesignLite project's
default.css has the IDateProviderItemRendererMapper for the Tabs and
TabBar components specified as TabsItemRendererFactoryForArrayListData.
But the dataProvider being supplied to the tab components were Arrays and
not ArrayLists. 

I changed the data models to supply ArrayLists for the dataProviders and
now the tabs are working. I think our changes together made this work
again.

Perhaps MDL should have a single item renderer data factory that is
universal in that it can accept either Array or ArrayList data and help
prevent this from happening in the future. I set this type of thing up in
the Express package (which I still have to test, now that I write this).

This is the feature/chart-work branch.

Regards,
Peter

On 4/9/17, 6:26 PM, "piotrz"  wrote:

>Ahh I forgot to mention that you can see issue when you look into
>MDLExample.
>Main TabBar do not display Tabs.
>
>Basically in TabBarView itemsCreated method has not been called.
>
>If you lost in there I will put some basic example.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmODB
>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I will look into it and let you know. I changed the life cycle for lists
just a little. I found that the item renderers were being created more
than once (sometimes) and the layouts were being run several times
(sometimes) so I tracked down redundant event dispatches and eliminated
them. Then I went back through examples to see what was depending on the
eliminated events and adjusted them. This is probably the same case. Once
this works out the event flow should be consistent.

‹peter

On 4/9/17, 6:26 PM, "piotrz"  wrote:

>Ahh I forgot to mention that you can see issue when you look into
>MDLExample.
>Main TabBar do not display Tabs.
>
>Basically in TabBarView itemsCreated method has not been called.
>
>If you lost in there I will put some basic example.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmODB
>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Greg Dove]

Actually I wasn't sure whether the compiler eliminated the dead js code.
But we know that it can.

I get the point about the 'swiss-army-knife' but I don't think that applies
here, because I think this is more a 'standard tool'. I can only directly
recall one Flex project in the last 6 years that did not require the swf
crossdomain security model. Perhaps I have forgotten some, but I suspect
that the world is becoming more interconnected, not less. I know there will
definitely be some who don't need this, and I guess there are certain types
of application that always will be single-domain. But unless I
misunderstand, it sounds like this need might be more for the majority than
the minority.

The point about the GCC stuff though I think is a little contrasting to the
PAYG philosphy elsewhere.

"AFAIK, public APIs have @export and are kept around.  Which will be a
good thing
in multi-module apps some day."

It sounds like we are keeping a lot of code that could be optimized or
automatically excluded because it will be a good thing "some day" (the day
when we support module loading). That sounds like the opposite of PAYG to
me, because many projects may not need 'module loading' (and we don't have
this yet anyway). I'm just trying to throw a potentially different way of
looking at this in here, because, in theory at least, the closure compiler
should be able to make a whole bunch of stuff go away in the release build
if it is not used (dead code elimination, DCE). In practice, I have not
tried it with any sizeable codebase, but I know other typedLanguage-toJS
compilers get the job done here, and I know that things like including
reflection data or not are also choices included in the options for output
in at least one other toJS compiler.

If this can work properly then we could actually have our cake and eat it
too. And yes the future might mean other things for modules, but perhaps
there are ways to get that working even with the renaming (DCE maybe not so
much, I agree).






On Mon, Apr 10, 2017 at 8:32 PM, Justin Mclean 
wrote:

> Hi,
>
> >  And the net result should be that code you didn't in your app, isn't in
> your app.
>
> As Greg pointed out the compiler can removed unused JS code i.e. methods
> that are not called. See for instance [1] for details. So in this case if
> you don’t use it will not end up in the AS code (as it’s JS only) and will
> not end up in production JS code.
>
> > So when you break stuff out into a bead, we want the net code size and
> performance for
> > someone not using the bead to be the same or better.
>
> In this case it is the same, if it was moved to a bead it would be worse
> for people who needed it. Only by tiny amounts but that’s the point you’re
> trying to make i.e. slow dead by a 1000 tiny additions, and as you say lots
> of people will need CORS support.
>
> > It is certainly worth revisiting the code we've written to see if other
> > stuff can be pulled out into beads, so thanks for reviewing HTTPService.
> > It is one of the early classes and probably needs a review.  Given the
> > above, my responses are inline below.
>
> We should provide clear documentation on this, currently there is none?
> Having our own code not following the same philosophy is a barrier for
> people contributing. In most other Apache projects if someone submits a
> patch that may not be “perfect” other committers will help to improve it.
> Pull request welcome and all that.
>
> > Possibly.  As long as the implementation for folks not using headers
> would
> > be smaller/faster.
>
> That is likely to be the case, but it will be slower for people who do use
> headers. How do we determine what is the most common use case? Isn’t that
> going to vary by use / customer so we going to end penalising someone no
> matter which way we go.
>
> > Possibly, but I claim that nobody should go into production without
> > supporting timeouts, so I would leave that baked in.
>
> So why does this not apply to the method I added? Every single project
> I’ve worked on has made cross domain calls. It's very uncommon for web
> applications to have their database, rest services, API calls on the same
> domain and quite common to call 3rd party services.
>
> And I’m sure no one would go into production without supporting security
> of some form. I’m concerned her that we are making security an optional
> feature here and not having it supported by default.
>
> > Again, if you can find a way to refactor that out without making the
> > HTTPService bigger/slower, then great.
>
> Anytime you place something in a bead it is going to be bigger and slower
> for the people that need that functionality. It will be faster/smaller for
> the others who don't. So again how do we determine what is the most common
> use case? Do more people use AIR status code than don’t use them? I would
> guess not in this case and it should be a bead but it’s just a guess.
>
> > Like Timeout, I claim that 

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Justin Mclean]

Hi,

>  And the net result should be that code you didn't in your app, isn't in your 
> app.

As Greg pointed out the compiler can removed unused JS code i.e. methods that 
are not called. See for instance [1] for details. So in this case if you don’t 
use it will not end up in the AS code (as it’s JS only) and will not end up in 
production JS code.

> So when you break stuff out into a bead, we want the net code size and 
> performance for
> someone not using the bead to be the same or better.

In this case it is the same, if it was moved to a bead it would be worse for 
people who needed it. Only by tiny amounts but that’s the point you’re trying 
to make i.e. slow dead by a 1000 tiny additions, and as you say lots of people 
will need CORS support.

> It is certainly worth revisiting the code we've written to see if other
> stuff can be pulled out into beads, so thanks for reviewing HTTPService.
> It is one of the early classes and probably needs a review.  Given the
> above, my responses are inline below.

We should provide clear documentation on this, currently there is none? Having 
our own code not following the same philosophy is a barrier for people 
contributing. In most other Apache projects if someone submits a patch that may 
not be “perfect” other committers will help to improve it. Pull request welcome 
and all that.

> Possibly.  As long as the implementation for folks not using headers would
> be smaller/faster.

That is likely to be the case, but it will be slower for people who do use 
headers. How do we determine what is the most common use case? Isn’t that going 
to vary by use / customer so we going to end penalising someone no matter which 
way we go.

> Possibly, but I claim that nobody should go into production without
> supporting timeouts, so I would leave that baked in.

So why does this not apply to the method I added? Every single project I’ve 
worked on has made cross domain calls. It's very uncommon for web applications 
to have their database, rest services, API calls on the same domain and quite 
common to call 3rd party services.

And I’m sure no one would go into production without supporting security of 
some form. I’m concerned her that we are making security an optional feature 
here and not having it supported by default.

> Again, if you can find a way to refactor that out without making the
> HTTPService bigger/slower, then great.

Anytime you place something in a bead it is going to be bigger and slower for 
the people that need that functionality. It will be faster/smaller for the 
others who don't. So again how do we determine what is the most common use 
case? Do more people use AIR status code than don’t use them? I would guess not 
in this case and it should be a bead but it’s just a guess.

> Like Timeout, I claim that nobody should go into production without
> handling errors.  So probably, the JS errors need to be handled right in
> HTTPService or HTTPServiceBase. 

So you're saying that HTTPService is where JS security errors should be handled 
and not in a bead?

Thanks,
Justin

1. https://developers.google.com/closure/compiler/docs/api-tutorial3

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Alex Harui]

Another way to think about it:  It would be awesome if, as a customer used
a code coverage tool to test their app, that the code coverage of the
framework code in their app reached 100% as the customer's code coverage
reached 100%.  Such a thing is generally never going to happen for regular
Flex apps.

-Alex

On 4/9/17, 11:14 PM, "Alex Harui"  wrote:

>At the highest level, the reason for beads and PAYG is not just for SWF
>code, it is for JS code as well.  And the net result should be that code
>you didn't in your app, isn't in your app.  Lots of people will need CORS
>support, but lots of people won't.  Now we could go overboard putting
>every method in its own bead, but that won't help the folks who aren't
>using some feature as the overhead would overwhelm the advantages of not
>carrying around the code of a feature that isn't used.  So when you break
>stuff out into a bead, we want the net code size and performance for
>someone not using the bead to be the same or better.
>
>Harbs is right that this is a completely different way of thinking about
>code than for the regular Flex SDK.  The philosophy of "it's only a little
>bit of extra code" is why the regular Flex SDK's UIComponent is 13,000
>lines long.  And why I had several unhappy customers bring their Flex app
>to me looking to save size and performance and I had to tell them that the
>cost of refactoring UIComponent was too high and they were out of luck.
>
>It is certainly worth revisiting the code we've written to see if other
>stuff can be pulled out into beads, so thanks for reviewing HTTPService.
>It is one of the early classes and probably needs a review.  Given the
>above, my responses are inline below.
>
>On 4/9/17, 7:14 AM, "Justin Mclean"  wrote:
>
>>Hi,
>>
>>> Therefore code to deal with authentication should not be in the base
>>>component.
>>
>>So in that case should the code dealing with HTTPs headers should be
>>removed?
>
>Possibly.  As long as the implementation for folks not using headers would
>be smaller/faster.
>  
>>
>>I can see the class is also dealing with timeouts should that also be
>>removed and placed in a bead?
>
>Possibly, but I claim that nobody should go into production without
>supporting timeouts, so I would leave that baked in.
>
>>
>>The class is also missing JS implementations of addBead, getBeadByType
>>and removeBead so it currently doesn’t support beads on the JS side. I
>>assume we will need to add JS implementations of those methods?
>
>Yes, if they are actually missing.  It looks like HTTPService is an
>Istrand, so I'm surprised about that.
>
>>
>>The method send deals with AIR only HTTP status events, that seems like
>>it should not be there at all? Why isn’t that a bead?
>
>Again, if you can find a way to refactor that out without making the
>HTTPService bigger/slower, then great.
>
>>
>>It only has SWF version of error handlers to deal with various AS errors
>>surely that also should also be a bead?
>
>Like Timeout, I claim that nobody should go into production without
>handling errors.  So probably, the JS errors need to be handled right in
>HTTPService or HTTPServiceBase.  Maybe there should be a common set of
>events generated.
>
>Thanks,
>-Alex
>

Re: git commit: [flex-asjs] [refs/heads/develop] - CORS security. Allow auth credentials to be passed when using cross site calls. This is required as well as setting the Access-Control-Allow-Origin h

[Alex Harui]

At the highest level, the reason for beads and PAYG is not just for SWF
code, it is for JS code as well.  And the net result should be that code
you didn't in your app, isn't in your app.  Lots of people will need CORS
support, but lots of people won't.  Now we could go overboard putting
every method in its own bead, but that won't help the folks who aren't
using some feature as the overhead would overwhelm the advantages of not
carrying around the code of a feature that isn't used.  So when you break
stuff out into a bead, we want the net code size and performance for
someone not using the bead to be the same or better.

Harbs is right that this is a completely different way of thinking about
code than for the regular Flex SDK.  The philosophy of "it's only a little
bit of extra code" is why the regular Flex SDK's UIComponent is 13,000
lines long.  And why I had several unhappy customers bring their Flex app
to me looking to save size and performance and I had to tell them that the
cost of refactoring UIComponent was too high and they were out of luck.

It is certainly worth revisiting the code we've written to see if other
stuff can be pulled out into beads, so thanks for reviewing HTTPService.
It is one of the early classes and probably needs a review.  Given the
above, my responses are inline below.

On 4/9/17, 7:14 AM, "Justin Mclean"  wrote:

>Hi,
>
>> Therefore code to deal with authentication should not be in the base
>>component.
>
>So in that case should the code dealing with HTTPs headers should be
>removed?

Possibly.  As long as the implementation for folks not using headers would
be smaller/faster.
  
>
>I can see the class is also dealing with timeouts should that also be
>removed and placed in a bead?

Possibly, but I claim that nobody should go into production without
supporting timeouts, so I would leave that baked in.

>
>The class is also missing JS implementations of addBead, getBeadByType
>and removeBead so it currently doesn’t support beads on the JS side. I
>assume we will need to add JS implementations of those methods?

Yes, if they are actually missing.  It looks like HTTPService is an
Istrand, so I'm surprised about that.

>
>The method send deals with AIR only HTTP status events, that seems like
>it should not be there at all? Why isn’t that a bead?

Again, if you can find a way to refactor that out without making the
HTTPService bigger/slower, then great.

>
>It only has SWF version of error handlers to deal with various AS errors
>surely that also should also be a bead?

Like Timeout, I claim that nobody should go into production without
handling errors.  So probably, the JS errors need to be handled right in
HTTPService or HTTPServiceBase.  Maybe there should be a common set of
events generated.

Thanks,
-Alex