[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] getRemoteServiceReferences...adding non-blocking impl
|
I've created enhancement request to track this addition
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251897
and proposed a new method call on IRemoteServiceContainerAdapter to
implement. Those interested in following/participating in this design
please join and comment on that enhancement request.
Scott
Scott Lewis wrote:
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev