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