On 4/16/17, 11:00 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >> So, good first try at a bead. Maybe we don't agree on the scenario. >>It >> looked like this bead was considering a scenario where on one call, you >> might set withCredentials=true, and on a subsequent call, you might set >> withCredentials=false, > >Yes I said that was a requirement in one of my emails. It also why the >function accepted it as a parameter rather than just setting it to true. > >> in which case you don't want to remove the listeners in postSend. > >AFAIKS you do want to remove them, otherwise if you called send again >they are replaced and there’s a potential for a memory leak. If you remove the preSend listener in the postSend, how will your logic ever see the next send? IMO you have to leave the listeners on and do any cleanup in the strand setter. But again, I don't think most beads need to worry about being removed. The major use of beads is for compile-time and startup-time configuration, not runtime configuration after startup. > >> So, by encapsulating this code in a bead, a simpler version can be >>used for the >> "set it once" crowd, and this more elaborate version could be used by >> someone who does want to change withCredentials in different calls. > >So I should create an extra bead CORSWithCredentialsIsTrueBead where is >it always true? Where user authentication is used there is probably >always going to be a least one call i.e. the login call before the user >is authenticated that you don’t want to pass the credentials on. I would >guess that having the ability to set it would be the more common use case >so this extra bead is probably not needed. I don't know much about CORS. If you make a login call in order to authenticate the user and the server you call with the login is on a different domain, how do you get the transaction to happen if withCredentials are false? I would add the very simple CORSWithCredentialsIsTrueBead because we want to give our users choices and there are plenty of ways to get the login that don't require the more elaborate bead you have proposed, such has having a separate HTTPService instance for the login and another one for other transactions. -Alex
