nice discussion. My application is a similar case to the one described by Christian. If a user doesn't want to have it activated because it consumes energy but an application decides that it is important to send a message using DTN, then this app should be able to enable the service. It is the same argument as deciding why to let an application to enable or disable the wifi or the bluetooth interface and you can do it just including these permissions on the manifest. Maybe this is the solution, creating a new permission (enable dtn) and then letting the user decide if accepting or not these permissions.
Abraham.
Am 29.01.2014 12:29, schrieb Christian Raffelsberger:
> For instance, we have written a prototype application that can be used
> by fire fighters or other first responders to locate victims. One
> feature that we experiment with is using the bundle protocol to send
> collected data to the command post. One of the most important
> requirements is to minimize user intevention (i.e., the fire fighter
> just activates the device and puts it in his/her pocket). In that case
> it is not feasible that the fire fighter manually starts the daemon.
Why is the daemon not enabled by default in that case? Are the energy
constrains are too hard? If "activate the device" means switching the
whole device on, the daemon would automatically start-up if the device
is booted.
Recently, I have been working on an approach to minimize the energy
consumption by disabling the discovery beacons. In this "smart" mode,
beaconing is activated only for 2 minutes if the Wi-Fi network is
switched. Maybe switching off the daemon for your scenario is no longer
necessary with that mechanism.
Kind regards,
Johannes Morgenroth