Re: [ecf-dev] Async-Methods

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Eugen and all,

As Markus correctly indicated, it's not necessary to create a second 
service registration for asynchronous remote access.  For everyone's 
reference, there is some example code and preliminary explanation of the 
asynchronous remote services support here [1].

All that's necessary for consumers to use the asynchronous support to 
declare a well-formed <service>Async interface...e.g. like Eugen has 
done with IExampleServiceAsync (Markus is correct that currently it must 
be in same package and bundle as the IExampleService).   And Markus is 
also quite right that if the original service method is (e.g.):

public String getName();

then the correct form for the asynchronous callback method is:

public void getNameAsync(IAsyncCallback<String> callback);

Alternatively if the original form for the method has parameters...e.g.

public String getName(String param);

Then the async callback form would be:

public void getNameAsync(String param, IAsyncCallback<String> callback);

The general rule for the IAsyncCallback is that it is assumed to be the 
last parameter...i.e. after any existing ones.

Note also that there are *two* forms supported for async method 
access...the IAsyncCallback is one, and IFuture is the other...so for 
example the IExampleServiceAsync can also have:

public IFuture getNameAsync();

This doesn't have to be present in the IExampleServiceAsync interace, 
however.  But if either form or both are present, they can be used.

Note that the returned type of IFuture.get() will be the same as the 
return value for getName() in the original service interface (String in 
this case).  I'm trying to get the addition of generics to the graduated 
concurrent API [2] (I'm the author/contributor of the Equinox concurrent 
API...but I need to get the Equinox committers to actually apply the 
desired changes...thus the bug [2]).  With a graduated concurrent API, 
one would be able to write declarations like this:

IFuture<String> getNameAsync();

and call

String result = future.get();

I think this would make the IFuture a little more usable/more accessible.

There is also some blog postings by me about asynchronous remote 
services [3] (which is cool if you ask me).  More docs and examples are 
certainly needed...please join and contribute to the ECF documentation 
project [4].

One final thing...I've started but not yet completed an Eclipse plugin 
that uses annotations to automatically create the <service>Async 
interface.  For example, you could do something like this:

@AsyncService
public interface IExampleService {

public String getName();

}

and Eclipse and the java6 annotation processor would/will create the 
IExampleService async class (and all methods) for you.  The bundle is in 
the incubation area here [5].  If others would like to contribute to 
this annotation processor please open an enhancement request and we'll 
coordinate on finishing it (what's there barely works).

Thanks,

Scott

[1] http://wiki.eclipse.org/Asynchronous_Proxies_for_Remote_Services
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247
[3] 
http://eclipseecf.blogspot.com/2010/09/asynchronous-remote-services-choices.html 

http://eclipseecf.blogspot.com/2010/04/asynchronous-remote-services-future-or.html 

http://eclipseecf.blogspot.com/2010/04/asynchronous-remote-services-part-2.html
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329124
[5] 
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/incubation/bundles/org.eclipse.ecf.remoteservice.apt.java6