On 07/05/10 16:46, Raphael Coeffic wrote: > Frankly, I don't like this approach too much, as there is a million > cases it could go wrong. I think we should have all the state changes > tailorized into one function (setState), which would then call some > onStateChanged(old_state,new_state). This is much closer to our fsm > strategy.
Yeah, smth. like setState() also crossed my mind. Some onStateChgd() would also be OK, though there are lots of callbacks [already :-) ]. > > Concerning the specific problem with authentication, Stefan and I were > in favor of moving the code into trunk. Any other suggestions? Sure, but would be cool to keep current capability allowing each app to instantiate it's own "authenticator"; like now, having a registration agent, but also some caller session, each using different credentials. Regards, Bogdan. _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
