Community
Participate
Working Groups
Discovery consumer usually don't care about the specific container used to discover a certain service. Also they might want to use several discovery containers simultaneously while discovering for a service. Thus a CompositeContainer should be available that makes using more than one specific container transparent.
Created attachment 77967 [details] first draft how a composite container might look like
Created attachment 79065 [details] version bump of this patch
"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)." What do you think about having a new bundle o.e.discovery.util where we implement the CompositeDiscoveryContainer? I could start with it on ecf1.osuosl.org.
(In reply to comment #3) > "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)." > > What do you think about having a new bundle o.e.discovery.util where we > implement the CompositeDiscoveryContainer? I could start with it on > ecf1.osuosl.org. > Sure. Let's call it org.eclipse.ecf.provider.discovery. If you would like to start on ecf1.osuosl.org that would be great. I would suggest just creating it at dev.eclipse.org, but since you don't have commit rights for ECF that's not an option right now. Would you like to become an ECF committer Markus?
(In reply to comment #4) > Sure. Let's call it org.eclipse.ecf.provider.discovery. If you would like to > start on ecf1.osuosl.org that would be great. I'll start working on it tomorrow on osuosl.org. > I would suggest just creating it > at dev.eclipse.org, but since you don't have commit rights for ECF that's not > an option right now. Would you like to become an ECF committer Markus? > Lets have a vote, shall we? Btw. if I later transfer my work from osuosl.org -> dev.eclipse.org as an official Eclipse committer, do we get around the CQ thingy?
(In reply to comment #5) > (In reply to comment #4) > > Sure. Let's call it org.eclipse.ecf.provider.discovery. If you would like to > > start on ecf1.osuosl.org that would be great. > > I'll start working on it tomorrow on osuosl.org. > > > I would suggest just creating it > > at dev.eclipse.org, but since you don't have commit rights for ECF that's not > > an option right now. Would you like to become an ECF committer Markus? > > > > Lets have a vote, shall we? Of course. I was just asking if you wanted to do this. > > Btw. if I later transfer my work from osuosl.org -> dev.eclipse.org as an > official Eclipse committer, do we get around the CQ thingy? > No...I wish it were so, but it's not.
Setting target milestone to 2.0.0M4
Fixed in HEAD (some time ago)
closing.
