I read into the remoting code recently and I think it certainly is a
good idea to use threading
for the parsing of the data (big soap files: lot to process). Generally
speaking: Server side processes
run in a different thread (on the server itself!) and xml/json/etc. is
just a mean of communication.
It would be awesome to have a api that makes use of the promises:
Promise result = api.operation("1234");
in that way we could "stack" calls to the api and get the results.
However that would be
a complete rewrite of rpc, which tbh. is not that bad of an idea.
yours
Martin.
On 22/03/2012 17:37, 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
