W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Rethinking availability monitoring

From: Oleg Beletski via GitHub <sysbot+gh@w3.org>
Date: Tue, 12 May 2015 07:55:53 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-101177305-1431417352-sysbot+gh@w3.org>
Not being able to stop discovery looks like a functional gap to me in 
addition to performance issues.

Here is what I was able to find:

According to  "UPnP Device Architecture 2.0" document [1] discovery 
process works like that:
- When a control point is added to the network, the UPnP discovery 
protocol allows that control point to search for devices of interest 
on the network. 
- When a device is added to the network, the UPnP discovery protocol 
allows that device to advertise its services to control points on the 
network (multicast).

In the first case waiting time for advertisement response after search
 request can be limited, so cancelling is less important. In the 
second case control point continuously listens for the notifications 
until it is stopped. We need cancel method here if we want to stop 
discovery.

Other example is Samsung Media Control SDK [2]. In Samsung Media 
Control SDK 1.0.4 discovery is handled by `SmcDeviceFinder` class that
 has `start` and `stop` methods to control discovery process.

Same functionality exists in Android's `MediaRouteProvider`, where 
discovery can be switched on/off with the help of 
`setDiscoveryRequest` method [3].

I think that the latest interface update proposed by @mfoltzgoogle  
https://github.com/w3c/presentation-api/issues/81#issuecomment-101039366
 will get the job done for discovery stopping as well.

[1] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf
[2] http://developer.samsung.com/galaxy#media-control
[3] 
http://developer.android.com/reference/android/support/v7/media/MediaRouteProvider.html

-- 
GitHub Notif of comment by obeletski
See 
https://github.com/w3c/presentation-api/issues/81#issuecomment-101177305
Received on Tuesday, 12 May 2015 07:55:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 May 2015 07:55:54 UTC