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" <jus...@classsoftware.com> 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
