Bug 29992

Well this could be resolved in two different ways:

1) The master server could keep track of all of its subscribers and call a well known method on the subscribed clients when the timer for that client has expired. The handling of this method would be take care of by a client library.

2) The client end could filter to only get signals with a specific parameter set. So when you subscribe you would get as a reply an id which would be given in the signal, so you can filter on it. This would be done by some client library for you, so you wouldn't have to worry about the specifics.

@Wolf: Yes, option 1 sounds like the correct way. In option 2 every application must wake up for every update to check this specific parameter, and that is exactly what is bug is about.

We agree that (2) is bad.  (1) would mean that instead of one signal being send to the bus daemon and the bus daemon sending it to all registered listeners we have to send N messages to each listener.  While this would involve less wakeups, we're massively increasing the amount of traffic on the bus.

Personally I don't think per-application rate limiting is that useful.  If every app on the device that wants position updates only wants a position every minute, then we should send the signals every minute.  If there is one that wants updates every second then we're already waking the CPU up, so will the extra notifications really be noticeable when compared with the extra workload that the alternatives imply?

I'm not sure if sending a signal per client would really flood the bus. Consider if there are three apps, one app needing every second, second app needing every minute, third one every five minutes. Over five minutes period of time, this would result in 306 messages (300 for the first app, five for the second, and 1 for the third), of which 6 are now extra. I think its fairly small percentage considering that 600 application wakeups/process switches are avoided (the "minute" applications don't need to wake up to see if their timer is running).

That is unless I've misunderstood how the dbus here works :)

On another (side)note, I have a feeling that many applications don't need updates exactly at the interval they requested. But rather they could specify range/accuracy for their updates which potentially could enable ways of grouping the signals better.  Perhaps a bit high flying thought for the bug at hand though...

Closing all bugs on old geoclue. If your bug still applies to new geoclue, please do re-open, I really don't have time to go through each and every bug and evaluate separately. :( Apologies for any inconvenience caused by this change.