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:17:58 GMT
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.


On 4/9/17, 11:14 PM, "Alex Harui" <aharui@adobe.com> 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" <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