Currently SharpRemote is able to (almost) hide away the fact that an object resides in a different process, however the new classes of failures which can now occur are not handled just yet and must be handled by the user. This is extremely cumbersome and should be simplified so that the following classes of errors are automatically handled:
Timeouts
By default a method call via SharpRemote never times out but blocks endlessly until either a (network) failure occurs or the called method returns. This may be convenient in some cases, but at other times you don't want to be at the mercy of a (remote) service: It should therefore be possible to have both synchronous and asynchronous method calls time out and throw a RemoteProcedureCallCanceledException.
Automated retries
We've all been there: You have an API and it does what it should do in 99% of the cases, but every 100th time, it throws. Proxies generated by SharpRemote should allow for automated retries to be performed (such as exponential backoff) until a method succeeds or enough retries have been performed.
Fallbacks
Suppose you have an API such as
public interface ISomeStorage
{
bool TryStore(objec[] data);
}
and you're using it over SharpRemote. Obviously this method will now throw countless exceptions (such as RemoteProcedureCallCanceledException) but you don't want callers to have to deal with those. You could write a proxy implementation, but you could also have SharpRemote do this for you.
The goal of fallbacks is to generate proxies which handle all failures (in the form of exceptions) and have them call a fallback implementation instead. This implementation could either be default generation (such as each method returning default(T)) or user supplied. In either way, a user no longer needs to handle failures, but merely specify what should be done in case a fault occurs.
Conclusion
A proxy capable of automatic timeouts, retries and a fallback will be extremely fault tolerant and be able to hide most failures from its user: It's behaviour only needs to be defined once and every of its user will reap the benefits of not having to care about failures anymore.
Currently SharpRemote is able to (almost) hide away the fact that an object resides in a different process, however the new classes of failures which can now occur are not handled just yet and must be handled by the user. This is extremely cumbersome and should be simplified so that the following classes of errors are automatically handled:
Timeouts By default a method call via SharpRemote never times out but blocks endlessly until either a (network) failure occurs or the called method returns. This may be convenient in some cases, but at other times you don't want to be at the mercy of a (remote) service: It should therefore be possible to have both synchronous and asynchronous method calls time out and throw a RemoteProcedureCallCanceledException.
Automated retries We've all been there: You have an API and it does what it should do in 99% of the cases, but every 100th time, it throws. Proxies generated by SharpRemote should allow for automated retries to be performed (such as exponential backoff) until a method succeeds or enough retries have been performed.
Fallbacks Suppose you have an API such as
and you're using it over SharpRemote. Obviously this method will now throw countless exceptions (such as RemoteProcedureCallCanceledException) but you don't want callers to have to deal with those. You could write a proxy implementation, but you could also have SharpRemote do this for you.
The goal of fallbacks is to generate proxies which handle all failures (in the form of exceptions) and have them call a fallback implementation instead. This implementation could either be default generation (such as each method returning default(T)) or user supplied. In either way, a user no longer needs to handle failures, but merely specify what should be done in case a fault occurs.
Conclusion A proxy capable of automatic timeouts, retries and a fallback will be extremely fault tolerant and be able to hide most failures from its user: It's behaviour only needs to be defined once and every of its user will reap the benefits of not having to care about failures anymore.