Pass DiscoveryServiceCallback also to DiscoveryParticipants #5526
Conversation
DiscoveryParticipants may also implement the ExtendedDiscoveryService interface to obtain a DiscoveryServiceCallback. Fixes eclipse-archived#4630 Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
| @@ -147,14 +152,24 @@ private void scan() { | |||
|
|
|||
| @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC) | |||
| protected void addMDNSDiscoveryParticipant(MDNSDiscoveryParticipant participant) { | |||
| if (participant instanceof ExtendedDiscoveryService) { | |||
| ((ExtendedDiscoveryService) participant).setDiscoveryServiceCallback(discoveryServiceCallback); | |||
There was a problem hiding this comment.
I doubt that this will work: when the participants are added to the MDNSDiscoveryService the discoveryServiceCallback is not necessarily set.
There was a problem hiding this comment.
That is true, but therefore I have the loop over all participants when the callback is set.
This code here is for the case that later at runtime a participant is added, so it receives the callback as well.
|
To answer your question: With the callback you can access previous results and do whatever you like with them, that depends on the use-case. But you are right, for detecting duplicates we have the |
|
Can you give us some examples of concrete use cases? |
|
Use case - if the configuration contains an IP Address and that IP address changes, you need to update the prior result. EDIT: same applies really to any configuration option (port, etc) - but ip address is easy to illustrate |
|
@tmrobert8 That is a perfect example why we do NOT want to introduce this feature - because people believe they have to do such things. Instead, the framework already takes care of updating existing inbox results, when you re-discover the same Thing UID but with changed configuration parameters. |
|
We should reflect this in the docs. The mechanism of updating current inbox results and existing things is not part of the discovery service description. Also the ExtendedDiscoveryService is explicitly mentioned to get hold of existing results/things. |
|
I agree with @htreu - I never realized the inbox item is automatically updated and that should documented. |
|
Who is volunteering to do so? |
|
I'd have no issues documenting this once it's been merged |
|
Maybe I have missed something, but as far as I understood, the documentation would actually document, why this PR here is NOT needed, so I don't see why we would have to wait for it to be merged... |
|
@kaikreuzer As for this PR - I still think it's valuable to have (unless you tell me there is a better way!). My comments about updating the config apply to the existing thing. Example: let's say I have an MDNS item (the NEEO brain) that I have added to my system. If the NEEO Brain acquires a new IP address, the MDNS discovery will see the new IP address and I can update the thing's configuration directly. Same applies to Sony when the stupid TV changes port numbers and the UPNP discovery is notified of the change. |
|
@tmrobert8 What prevents you from doing this
without this PR? You simply create a new |
|
@triller-telekom |
Addresses eclipse-archived#5526- Signed-off-by: Henning Treu <henning.treu@telekom.de>
|
Please see #5583 for an updated documentation. With this I think we can close this one. |
Addresses #5526 Signed-off-by: Henning Treu <henning.treu@telekom.de>
Addresses eclipse-archived#5526 Signed-off-by: Henning Treu <henning.treu@telekom.de>
|
This pull request has been mentioned on openHAB Community. There might be relevant details there: |
DiscoveryParticipants may also implement the ExtendedDiscoveryService
interface to obtain a DiscoveryServiceCallback.
Fixes #4630
Signed-off-by: Stefan Triller stefan.triller@telekom.de