Skip to main content

[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



Back to the top