> Hi Aki,
> > > Honestly I don't like either approach, the Agent pattern would be a
> > > much better fit here. This would allow us to specify
> > > the polling/update interval and stop neighbor cell updates when no
> > > one is interested in them.
> > In my experience, the positioning guys don't need periodic updates at
> > all. The data needs to be fetched on demand. Like whenever the user
> > starts up a location-aware application.
> Fair enough, but we also have to consider the case of multiple
> being interested in this information. We can't assume that it will be
> polled on demand by just one...
Ny understanding is that typically there would be a location service that
queries this information from oFono and converts it into actual
coordinates through voodoo and black magic and that location-aware
applications will ask this location service for coordinates. E.g. you
would have something like GeoClue providing a single API for providing
coordinates to applications and under GeoClue there is the location
service, and the location service in turn talks to oFono.
You're absolutely correct. My point is that if only one entity is ever going
to be interested in this information (e.g. GeoClue) then a full blown atom /
DBus API is not even necessary. We can do this similarly to the history atom
and leave it up to the system integrator to decide how and what service to
DBus API implies that multiple user applications are interested in the
information provided. If this is the case, then in my view a procedural,
application-driven polling API is not the best approach.