Multi-client location access

[Enrico Mioso]

Dear All,

I am under the impression it's better to implement a new API as needed, breaking existing clients if necessary: I am under the impression we don't have a lot of MM clients using location services after all and furthermore I don't think
mmcli should be counted as one of them since it lives in the same repository as MM and so it can be updated accordingly.

My 2 cents here.

On Tue, Dec 17, 2024 at 07:57:57AM -0600, Dan Williams wrote:
> On Mon, 2024-12-09 at 13:35 +0100, Teemu Ikonen wrote:
> > Hi,
> > 
> > In Geoclue we're wondering
> > (https://gitlab.freedesktop.org/geoclue/geoclue/-/merge_requests/176)
> > how to deal with multiple clients using ModemManager for location
> > info.
> > 
> > The straightforward approach of enabling location gathering on client
> > startup and disabling it on exit does not work, because other clients
> > will then stop receiving location updates. The MR above describes and
> > implements a protocol for turning location gathering on and off and
> > reacting to changes. I asked for feedback on this in MM issues
> > (https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issue
> > s/870) but got no replies. Any thoughts on this subject in this list?
> 
> Good question...
> 
> Out of curiosity, what other clients have you found using location info
> alongside GeoClue?
> 
> In any case, Aleksander and I talked about this last week and didn't
> think of a great solution. Instead we came up with a hybrid approach
> that may meet the needs of both long-lived clients (GeoClue) and short-
> lived ones (mmcli).
> 
> a) refcount location source enable/disable in MM based on D-Bus
> connection. When the D-Bus client goes away or drops off the bus, drop
> the reference. When all users have dropped off the bus, disable the
> location source.
> 
> b) to ensure we don't break mmcli and other tools that depend on the
> existing behavior that sources stay enabled over D-Bus connection
> changes, add a new API method that has the existing non-refcounted
> behavior, and switch mmcli to that. Would really use refcounting
> underneath though, but based on API start/stop requests instead of D-
> Bus client.
> 
> Yeah, in reality that does break tools like mmcli, but I'm not sure how
> we can really fix this otherwise. Adding a new ref-counted API would
> likely take years for all clients to switch over.
> 
> What do you think?
> 
> Thanks,
> Dan