I don't feel the async calls to networking API are a burden. I also have a strong dislike of lock'ing from Java, so I don't feel particularly enthusiastic about your example, but I can also see how this would be a common thing to do. Think of what happens if your first call ends up in an error? - will the lock be released? - if so, maybe the second part of the code shouldn't be executed? Or maybe it should? and so on. Well, it is too early to speculate about how the threading may look in AS3, but if I could have a wish, I'd rather it be done in a way it is in Erlang, then Java because it makes concurrency problems easier to spot / more similar to events we already have in Flash.
If there is any improvement I wish for Flash networking API it would be consistency. There is a handful of classes all having load() methods, but impossible to abstract because the signature of the load() is different (invariant types of context that is passed as a second argument). The division of responsibilities of the said classes is lacking structure. Some of them may be able to do the same thing, while not even being in any sort of relationship one to another. I'd be happy if Flash API followed more fairly the definitions of protocols they implement and provide some sort of abstraction to that. S.t. for example there would be an HTTP class that can connect, disconnect and expose the stream, while connected, similarly, RTMP class etc, all either inheriting or implementing the same superclass / interface. I don't know what's the purpose of Flex RPC packages. So, I don't really have an opinion on async tokens and such. That always seemed to me to be an attempt of adding yet another layer of indirection on top of something that already has few such layers. Best. Oleg
