RE: [ecf-dev]Customize selection of RemoteServices Providers to expose/

["Konradi, Philipp" <philipp.konradi@xxxxxxxxxxx>]

Hi Scott,

> > If yes: Task 1. requires very good knowledge of each available
> > provider... is the implementer of IHostContainerFinder extension
point
> > supposed to have it?
> >
> 
> Yes...but just to be clear the IHostContainerFinder is not an
extension
> point (yet), it's just a service interface.
So in case a new provider is installed into a container, how is an
IHostContainerFinder implementation supposed to know about the
capabilities of this new provider?

Philipp

> -----Original Message-----
> From: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Scott Lewis
> Sent: Wednesday, April 29, 2009 6:11 PM
> To: Eclipse Communication Framework (ECF) developer mailing list.
> Subject: Re: [ecf-dev]Customize selection of RemoteServices Providers
> to expose/ consume a service
> 
> Hi Philip,
> 
> Konradi, Philipp wrote:
> >
> > Hi all,
> >
> > in _http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02281.html_ as
> > well as in today's conf call Scott described and asked for comments
> > about the newest additions to RFC 119 / Distributed OSGi support:
the
> > IProxyContainerFinder / IHostContainerFinder interfaces as a way to
> > customize the selection of ECF Remote Services Providers to expose /
> > consume a service.
> >
> > I think that this extensions are important means for application
> > developers / ECF extenders and starting here a new thread to discuss
> > them and try to uncover missing point if there are some.
> >
> > When looking closely at the IHostContainerFinder interface:
> >
> > *public** interface* IHostContainerFinder {
> >
> > * public* IRemoteServiceContainer[] findHostContainers(
> >
> > ServiceReference serviceReference, String[] remoteInterfaces,
> >
> > String[] remoteConfigurationType, String[] remoteRequiresIntents);
> >
> > I've got the impression that a it fulfills two tasks:
> >
> > 1. Check which provider is capable to expose the service (based on
> > interface, intents, configuration, ...)
> >
> > 2. Select from multiple suitable providers the ones which should
> > actually take care of service exposure
> >
> > Is my understanding correct?
> >
> 
> Yes.
> 
> > If yes: Task 1. requires very good knowledge of each available
> > provider... is the implementer of IHostContainerFinder extension
point
> > supposed to have it?
> >
> 
> Yes...but just to be clear the IHostContainerFinder is not an
extension
> point (yet), it's just a service interface.
[Konradi, Philipp] 
So in case a new provider is installed into a container, how is an
IHostContainerFinder implementation supposed to know about the
capabilities of this new provider?

> 
> > This capability check is also required at the client/proxy side, to
> be
> > taken care by IProxyContainerFinder?
> >
> 
> Yes.
> 
> > Regards,
> >
> > Philipp
> >
> > P.S.: just a minor remark: Given that this extension point selects
> the
> > providers from the available ones and not really "finds" them, maybe
> > we should rename it to something like xxxContainerSelector?
> >
> 
> Calling it Selector would be reasonable if people prefer it...although
> a
> 'finder' is able to select from available ones *and/or* create new
> ones.
> 
> Again if people think Selector would be better (given that it can
> indeed
> create or select) I'm open to it...but we would have to come to
> consensus to make the name change quickly.
> 
> Thanks for questions and comments.
> 
> Scott
> 
> >
---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev
> >
> 
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev