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
