[
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>
Hi,
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).
Scott
With the
CompositeDiscoveryContainer CDC in place
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=200803), 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.
Markus
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
