Cosma,
It almost seems like most of your problem could be solved through code.
When I'm bootstrapping an application, I use a task framework to handle
multiple remoting calls. Most of them have asynchronous tasks. Cairngorm
3, PureMVC, and Robotlegs all have asynchronous task components
available, and I imagine the problem has been solved in other frameworks
as well. You usually end up with some main task class that has a list of
subtasks, which can by asynchronous or synchronous, or run in sequence
or parallel. PureMVC's implementation is particularly well done.
Once the tasks are created, you can fire off as many requests as your
browser will allow in parallel, which usually speeds up bootstrapping
considerably.
Robert
On 3/22/2012 2:37 AM, Cosma Colanicchia wrote:
Hi,
I've read about the new ActionScript workers, coming in one of the
next releases of the Flash Player: good news.
I wander if this could enable an improvement related to remoting:
frequently I need to perform multiple async remote calls to the
service layer, waiting for the result of one invocation before
starting the second, and so on. This usually results in a number of
result and fault event handlers that makes very hard to follow even
simple logic. Basically, because we miss a "sync remote call"
facility, or (in other words) the ability to pause the calling thread
until an async operation is completed.
I understand that with the current single-thread model this is
undesiderable, because locking the (only) thread would lock the entire
ActionScript execution, including UI refresh, blocking the user on the
current frame.
However, this could be a very useful feature in a worker thread,
because it would lock only that thread, without any impact on the app
responsiveness. I mean the ability to write something like:
public function mySyncFunction(value:String):String {
var firstToken:AsyncToken =
myService.getOperation("firstMethod").send(value);
lockForToken(firstToken); // allowed only in a worker
var firstMethodResult:String = firstToken.result as String;
var secondToken:AsyncToken =
myService.getOperation("secondMethod").send(firstMethodResult);
lockForToken(secondToken); // allowed only in a worker
return secondToken.result as String;
}
The same logic, implemented in the current way, usually requires 6
more methods (or closures): 4 to manage the faults/results of the
remote invocations, and 2 event handlers to receive the async result
of mySyncFunction. The added bonus of this feature would be that, in a
worker thread, we would be able to "break the async inheritance" that
currently force any method that use an async method (directly or
indirecty, anywhere in the nested call hierarchy) to be coded as an
async method itself.
I know this is flash player stuff, and that in the provided sample
there seems to be some "magic" in the asynctoken that would rather
belong to a synchronization primitive.. I just wanted to know what do
you think about the concept.
Cosma
