[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] getRemoteServiceReferences...adding non-blocking impl
|
Hi Markus,
Markus Alexande Kuppe wrote:
<stuff deleted>
+1 for public void requestRemoteServiceReferences(ID[] ids, String
className, String filter, IRemoteServiceListener listener)
To me listeners appear to be the more natural/simpler approach in
Eclipse land,
thanks for the feedback.
Well, that is true (listeners are more common in Eclipse than futures),
but I suspect that at least part of that is the limited platform-level
usage of JRE 1.5+...i.e. the concurrent api (which includes a future).
Also, I think at least so far Futures have just not been as widely used
in java-land...partially because they came on the scene much later (in
terms of implementation).
They (futures/asynchresults) are a quite convenient idiom (IMHO) for
doing asynchronous stuff.
whereas AsynchResult just adds extra convenience.
Also AsynchResult is mostly synchronized, thus might be slower.
This generally isn't a problem, actually.
I do agree that the listener approach is much more common, and so more
familiar. It's at least one reason why almost all existing ECF api uses
that approach.
Just my 2 cents
Markus
P.S. Why not name it getRemoteServiceReferences(ID[] ids, String
className, String filter, IRemoteServiceListener listener). IMO the
additional parameter makes it clear that it is asynchronous.
My thinking was that outside of ECF the listener is used so frequently
in the synchronous notification case (e.g. in SWT, OSGi event service)
that some additional API queue (request rather than get) would be
helpful. But perhaps you are right.
Scott
