"Wait for response" feature

[tommasobertoni]

This feature would be used in these two cases:

• when subscribing to a channel (the actual subscription is handled by the server, therefore asynchronously)
• when a response to a message is needed (e.g. you send a "request" and you want to receive the response to that particular message). This leverages the Id of the packets.

Based on the current idea, this feature will be implemented using Task and TaskCompletionSource, by using the Microsoft BCL Portability Pack to maintain compatibility with the .NET Framework 4.0.

UPDATE: The BCL is already included in Iris.NET from the version 0.2 (beta-2)

Usage

Subscription

Task<IDisposableSubscription> futureSubscription = node.Subscribe("worldnews", MyContentHandler);
IDisposableSubscription subscription = await futureSubscription;

Wait for a message's response

Guid messageId = node.Send("worldnews", "something good happened");
Task<object> futureResponseContent = node.WaitForResponse(messageId, timeout: null);
// The api will offer the possibility to pass in a timeout that will force the task to complete
// (with an exception, maybe?)
object content = await futureResponseContent;
// The content is received from both the "await futureResponseContent" call
// and from the subscription to the "worldnews" channel

The proposed usage will force to change the following method signatures in the IIrisNode interface:

• Send
• SendToBroadcast
• Subscribe
• SubscribeToBroadcast

UPDATE: IIrisNode has already changed its methods names (issue #2) and signatures to support Tasks with the version 0.2 (beta-2)

[tommasobertoni]

It should be noted that the Task completion in the beta-2 IIrisNode api does not correspond to the actual subscription to the server or the message reception by the target nodes: it's meaning is that the worker that handles outgoing communication has processed the message and therefore the data / command has been sent to the server (over the tcp connection).