Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Planned Discovery UI contribution

Hi Markus,

Markus Alexander Kuppe wrote:
Scott Lewis wrote:
<stuff deleted>

do we really need the compile time dependency?

Probably not.

With a slightly different
architecture I think we might get around it.

Perhaps...I was thinking, however, that it might be helpful to have some utility classes/new API in org.eclipse.ecf.remoteservices that 'knew' about IDiscoveryServices. But if we can avoid it without making people to 'too much' to do discovery of services, then that is fine with me. But I agree that there is utility in keeping them separate (although it would only be a RS->Discovery dependency).

WRT CompositeDiscoveryContainer, I'm thinking of having a new Namespace and Container type (in new bundle) that 'knows' about both the JMDNS and SLP-providers...and their respective IServiceID and ServiceTypeID namespace. It would probably be helpful also to define an extension point for such a bundle that allows other discovery providers to be contributed at load (extension) or run time (API).


With the
CompositeDiscoveryContainer CDC in place
(, we could build
it in a way that we use the SLP/ZeroConf/... containers for the
discovery of the remote OSGi runtimes. The newly written
RemoteServiceRegistryContainer would then listen for discovery events at
the CDC of the OSGi type and then query the remote runtime for services
and announce them via the CDC itself. For the discovery consumer this
would be totally transparent and even configurable. If the consumer
doesn't need OSGi remote service discovery, he simply doesn't register
the container.


ecf-dev mailing list

Back to the top