Re: [ecf-dev] Behavior of IDiscoveryContainerAdapter and service discove

[Markus Alexande Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

Scott Lewis wrote:
> 
> Why not have the SLP provider call serviceAdded and then serviceResolved?
> 
> Scott

Hi Scott,

that is how the current implementation looks like, but I'm rather
dissatisfied by it. The behavior is different to the existing JMDNS
provider in terms of threads. In JMDNS the consumer needs to call the
asynchronous requestServiceInfo which in turn cause the
container to call serviceResolved on the listener.

But in general I wonder if we really want to expose this JMDNS specific
behavior to the consumer. Why do we need this two staged approach of
serviceAdded and serviceResolved anyway? From a SPI perspective it
doesn't seem necessary. A service is either discovered or not.
Thus I propose to merge serviceAdded and serviceResolved with 2.0.

For JMDNS resolving the service could be done inside serviceAdded
automatically.

In case you disagree with the merge, I opt for changing the parameter of
requestServiceInfo(IServiceID) to IServiceInfo. That's what serviceAdded
gets called with anyway and what would allow other providers to simply
call serviceResolved from within requestServiceInfo.


Cheers
Markus