Re: RFC: API for Neighbouring Cell Info

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Hi Waldo,

> > 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
> > applications
> > 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 
use.

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.

Regards,
-Denis