Hi,
Async support on the server-side is important for scalability.
Equally important is a client side solution, which if services are
clients, is also important for scalability, or for good interaction
with UIs that need to process stuff asynchronously to avoid pauses.
There is the AsyncWebResource class that supports Future<T>, but we
need to extend this to support callbacks.
So we could do the following:
AsyncWebResource r = ...
CallBackStatus s = r.get(new CallBack<String>() {
void onError(Throwable e) { ... }
void onResponse(String s) { ... }
});
The CallBackStatus instance can be used to check the status and also
cancel.
(CallBack and CallBackStatus are not very good names).
Because of type erasure, the "String" type in the above example needs
to be known. It seems appropriate to make CallBack an abstract class
from which the type T can be determined:
public abstract class CallBack<T> {
protected CallBack() {
// Determine concrete Type of T
}
protected CallBack(Class<T> c) {
this.type = c;
}
Type getType() { ... }
public abstract void onError(Throwable e);
public abstract void onResponse(T t);
}
Then we require the ability to utilize async client APIs if they are
available from the underlying client implementation or a default
implementation that utilizes its own threading logic if there is no
async support in the underlying implementation.
Paul.