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

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



Back to the top