Udi is talking about some of the advantages of using spaces, tha ability to extend an existing infrastructure at runtime, simply by adding new clients and new tasks to a running grid/space. The idea is that there is an existing set of servers, which handles tasks from several queues. This separation of the servers that does the work from the clients that request is means that you can register new types of tasks and they will be handled automatically.

He also mentions a technological difference between Java and .Net. Apperantly, Jini on Java is capable of handling uknown types automatically, by downloading their byte code and dependencies. On the .Net side of things, we have no such facility built in, and if we would try to deserialize a task of an uknown type, we would get a serialization exception.

This difference pushed Udi to use a different style for this, instead of tasks that contains both behavior and data, use messages on the queue, and deploy message handlers to the servers. Personally, I like the zero deploy scenario, and I think that I like the idea of a task that encompass both data and behavior.

I have given to the issue of deploying some thought, and since we have strong versioning for .Net assemblies, it is really a matter of finding out what the assembly qualified name of the task is, and then go to a central server that has it if the server doesn't have it already. A nice advantage of this scheme is that you get the ability to handle versioning of tasks pertty much out of the box.

One thing that I am not so sure of is separation of clients from the decision process. That is, while a client may want to start the SendOrder process, is it really the responsability of the client to put a SendOrderUsingFedExTask on the queue? This seems like too much responsability, so maybe using messages here is preferred. Again, you can request message hanlders automatically, so you still get that benefit.