10:29 p.m.
Hi,
after some use of our DMC/DMP I found a lack in our API. We cannot refresh the list of
servers/renderers.
In the re-arch discussion we also talk about the fact services perform auto discovering at
launch and that could be unnecessary.
We can fix all these issues this way:
1 - Add a new API to perform a discovery. This will allow a DMP/DMC to refresh the list of
devices/services without waiting the 30 min timeout for some cases.
2 - Add settings for DMS/DMR to enable/disable auto discovering at launch
3 - If auto discovering is disabled, the call to GetServers() call first the new API
defined in 1)
Reminder: We are on local networks. So discover is pretty fast.
So in case of single service for DMS/DMR, customers can choose to disable auto discover
for one or both services and to perform the discover in their application manually when
they want. They now their needs, they can tune it.
In case of general use, like on desktop, I think we can enable the auto discover for both,
it won't be a problem. We can even make the service launch at boot time.
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
10:52 p.m.
Hi Ludo,
1 - Add a new API to perform a discovery. This will allow a DMP/DMC
to refresh the list of devices/services without waiting the 30 min timeout for some
cases.
How will you implement this API? I could be wrong here, but I don't
think there is a GUPnP API that performs a rescan of the network? I
think you would need to destroy and re-create the context manager to
implement this. What would happen to outstanding tasks issued by other
clients if you did this?
2 - Add settings for DMS/DMR to enable/disable auto discovering at
launch
3 - If auto discovering is disabled, the call to GetServers() call first the new API
defined in 1)
Reminder: We are on local networks. So discover is pretty fast.
So in case of single service for DMS/DMR, customers can choose to disable auto discover
for one or both services and to perform the discover in their application manually when
they want. They now their needs, they can tune it.
In case of general use, like on desktop, I think we can enable the auto discover for
both, it won't be a problem. We can even make the service launch at boot time.
Why bother? If we just keep the two services separate we don't need
this right? If people want to have DMS and DMR information available
immediately, they can arrange for the services to be run at startup. If
people don't want this, the services can be launched on demand via IPC
activation.
Ludo
12:16 a.m.
On 24/01/2013 12:52, Mark D Ryan wrote:
Hi Ludo,
> 1 - Add a new API to perform a discovery. This will allow a DMP/DMC to refresh the
list of devices/services without waiting the 30 min timeout for some cases.
>
How will you implement this API? I could be wrong here, but I don't
think there is a GUPnP API that performs a rescan of the network? I
think you would need to destroy and re-create the context manager to
implement this. What would happen to outstanding tasks issued by other
clients if you did this?
The functionality is easy to implement.
gssdp_resource_browser_set_active (False) to stop the discovering
gssdp_resource_browser_set_active (Start) to start the discovering.
So the refresh func should just call it twice, once to stop, once to relaunch the
discovery.
Then it's just a refresh/merge algo
-> For every device we already have in our list -> do nothing
-> after a timeout of x sec (we need to check the specs, or define ourself something
like 5sec), all remaining devices will be properly removed:
-> Cancel all pending task
-> notify device unavailable
-> delete device
> 2 - Add settings for DMS/DMR to enable/disable auto discovering at launch
>
> 3 - If auto discovering is disabled, the call to GetServers() call first the new API
defined in 1)
>
> Reminder: We are on local networks. So discover is pretty fast.
>
> So in case of single service for DMS/DMR, customers can choose to disable auto
discover for one or both services and to perform the discover in their application
manually when they want. They now their needs, they can tune it.
>
> In case of general use, like on desktop, I think we can enable the auto discover for
both, it won't be a problem. We can even make the service launch at boot time.
Why bother? If we just keep the two services separate we don't need
this right? If people want to have DMS and DMR information available
immediately, they can arrange for the services to be run at startup. If
people don't want this, the services can be launched on demand via IPC
activation.
Ok, fine with me. It was just a proposal.
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
1:07 a.m.
Hi Ludo,
The functionality is easy to implement.
gssdp_resource_browser_set_active (False) to stop the discovering
gssdp_resource_browser_set_active (Start) to start the discovering.
So the refresh func should just call it twice, once to stop, once to relaunch the
discovery.
Okay, I see. Currently, we create a control point for each context we
discover. We could force a refresh by keeping track of all the control
points we create and then calling gssdp_resource_browser_set_active
twice on each of these objects. This would force the refresh. But are
you sure it's safe to do this? Would doing so destroy all our service
proxies and re-create them? If so, this will cause problems for other
clients that have calls outstanding.
Regards,
Mark
1:21 a.m.
On 24/01/2013 15:07, Mark D Ryan wrote:
Hi Ludo,
> The functionality is easy to implement.
> gssdp_resource_browser_set_active (False) to stop the discovering
> gssdp_resource_browser_set_active (Start) to start the discovering.
>
> So the refresh func should just call it twice, once to stop, once to relaunch the
discovery.
>
Okay, I see. Currently, we create a control point for each context we
discover. We could force a refresh by keeping track of all the control
points we create and then calling gssdp_resource_browser_set_active
twice on each of these objects. This would force the refresh. But are
you sure it's safe to do this? Would doing so destroy all our service
proxies and re-create them? If so, this will cause problems for other
clients that have calls outstanding.
Regards,
Mark
Right. I need to check if we can do it by not modifying our current control_point.
Maybe we can create a new control for this feature, with its own callbacks, call
gssdp_resource_browser_set_active(true) on this cp and then compare the 2 lists of
devices. For devices that already exist, we do nothing and we don't need to take care
of device & service proxies.
For device we need to remove, it's easy.
Ludo
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
1:44 a.m.
Hi Ludo,
Right. I need to check if we can do it by not modifying our current
control_point.
Maybe we can create a new control for this feature, with its own callbacks, call
gssdp_resource_browser_set_active(true) on this cp and then compare the 2 lists of
devices. For devices that already exist, we do nothing and we don't need to take care
of device & service proxies.
For device we need to remove, it's easy.
It's certainly worth a try to see what happens. Perhaps it might also
be possible to add a refresh feature to GSSDP/GUPnP.
Regards,
Mark
3524
days inactive
3524
days old
5 comments
2 participants
participants (2)
-
Ludovic Ferrandis -
Mark D Ryan