[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[ecf-dev] getRemoteServiceReferences...adding non-blocking impl
|
Hi Folks,
In the remote services API, i.e. IRemoteServicesContainerAdapter, is
this method for doing lookup of remote services:
IRemoteServiceContainerAdapter.getRemoteServiceReferences(ID[],String,String)
Here are the current javadocs
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/IRemoteServiceContainerAdapter.html#getRemoteServiceReferences(org.eclipse.ecf.core.identity.ID[],%20java.lang.String,%20java.lang.String)
This method is the primary way for clients to 'lookup' a remote service
reference in the ECF remote services API.
In this bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=249061 we
introduce a on-demand service reference lookup, meaning that
getRemoteServiceReferences call can potentially block (because of the
messaging/IO involved in sending/receiving 'add proxy' request).
As a consequence I would like to consider creating a non-blocking (new)
version of getRemoteServiceReferences(). That is, I would like to add a
method like this:
public void requestRemoteServiceReferences(ID[] ids, String className,
String filter, IRemoteServiceListener listener)
that would not block, but asynchronously notify the listener when remote
service references were received. Another design for such a
non-blocking lookup method would be:
public AsynchResult requestRemoteServiceReferences(ID[] ids, String
className, String filter)
The AsynchResult is essentially a 'Future' result...allowing clients to
access the actual result delivered asynchronous inside of the AsynchResult.
Do people have thoughts about this? I think it would make sense to have
both a synchronous/blocking getRemoteServiceReferences (as we have now),
and an asynchrnous lookup method, either via the listener or the
AsynchResult.
Any thoughts/comments about this issue?
Scott