Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Behavior of IDiscoveryContainerAdapter and service discovery

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

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.


Back to the top