flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject 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 header on the server.
Date Mon, 10 Apr 2017 06:14:20 GMT
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" <justin@classsoftware.com> wrote:

>> Therefore code to deal with authentication should not be in the base
>So in that case should the code dealing with HTTPs headers should be

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.


View raw message