| Re: [ecf-dev] [GSOC Project Idea]-Looking for a GSoc Project in ECF |
|
Hi Salinda,
A couple of comments on your observations...that may be helpful for your proposal (please do get something into GSOC by 5/3 as Markus suggested...so that your project can be considered). See a couple of inline comments below. On 4/30/2013 3:43 PM, Salinda Jayawardana wrote:
Yes...these are the first two steps.
Note one thing...although in ECF 3 can be done explicitly/programmatically, it is not strictly necessary to create a remote container. That is, if 3 isn't done explicitly, when 4 is done (i.e. register the remote service with the OSGi service registry) in most use cases 3 can/will be done automatically by the ECF implementation of OSGi remote services. I would tend to concentrate on the workflow that focuses on tooling support for creating OSGi remote services...e.g: A) Create a service interface (which would possibly include annotations to specify the OSGi remote services meta-data...i.e. service properties) B) Create implementation of service interface C) Register the service with the OSGi service registry (this can be done in several ways...e.g. BundleContext.registerService, declarative services, others)...along with the service properties required by the OSGi remote service specification that will result in it being exported by one or more of the ECF config types (aka container types)). With the current impl of he ECF remote service admin, doing C will result in what you describe as 3 above. Further, with ECF's implementation of RSA this process of creating a remote container during/as part of export is customizable. Anyway...my main comment is that the tooling around remote services is conceptually simpler than the 4 steps you initially outlined...i.e. declare service interface, impl service, register service. Does that makes sense? If not let me know and we will discuss further.
[Scott] One approach that I was taking with the initial annotation work was that it was/is possible to create an Eclipse 'annotation processor' that when an annotation was added to a service interface (i.e. via Eclipse editor), another service interface could be automatically generated (and the generated service interface class would extend IAsyncRemoteServiceProxy). I'm not sure this is the best way to go, but it is one idea I had around supporting asynchronous remote services.
For the @Remote annotation, I would agree with your assertion above...that remote services would be registered. However, as I described above...one way to go would be to process the @AsyncRemote annotation (or whatever it ends up being called) at *editing time*, and have it create a new async service interface...with methods that return IFuture or have IRemoteService. This *could* be done at compile time (using Eclipse annotation processing tool...which supports extensible annotation processing in Eclipse).
In general...yes. Here's some of the thinking that remains to be done (and at least some of this can/could make a great gsoc project, IMHO): 1) What annotations should exist? 2) Should the annotations be processed/used at editing time (Eclipse apt), at runtime (reflection)? 3) How/whether these new annotations interoperate with the OSGi R5 standard annotations...e.g. @Component for declarative service components? 4) Are there annotations (and/or other tooling) for remote services could be considered for standardization (OSGi)? Thanks, Scott
|