Re: [ecf-dev] getRemoteServiceReferences...adding non-blocking impl

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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