new method/signal suggestions

[keith preston]

On 8/11/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
>
> keith preston wrote:
> > Please take a look and comment on anything else that we should add to
> the API.
>
> This is not fully thought out, but I have had these ideas:
>
> 1. position_changed signals with resolution
>
> gpsd position provider emits lots of signals*, but I assume many (most?)
> clients will not be interested in a change of a few meters... Would it
> make sense to have
>    position_changed_100m
>    position_changed_1000m
> or similar that will only be emitted after a larger change in
> position... (the method names are fictional and the implementation
> probably would have to be fuzzier, but you get the idea)
>
>    * currently gpsd backend emits the signal everytime gpsd updates
>    lat/lon, about twice a second with my device, but even if it emitted
>    only when lat/lon changes, there will the same amount of signals when
>    moving.


I don't think we should add signals for this,  however it would be easy to
add a filter function on the callback that can do this for any resolution.



2. last_position idea (you mentioned something like this already)
>
> However good our backends are, we should assume that it will be very
> common to not have current position data available from any backend. In
> many situations even older position data would do fine: A hostip
> position is going to be just as accurate in 30 minutes as it is now and
> a gps position from 10 minutes ago is still going to put you in the
> correct city...
> One option is to have a last_position-method in the API, and an
> accompanying last_position_error, which could rise over time. Clients
> that are interested in just getting an approximate position (that might
> be a bit old) should always use this method.
> Another option would be adding parameter to current_position that
> allows sending "old data" (and make position_error behave as described
> previously).


I think there are good reasons for this.   Loggers and Trackers need good
timestamps.   I think this also incoporates a last position type attribute
to the API, but I have quite got the semantics through my head yet.

The biggest problem I see is with inaccuracy of backends.   I think some
information, even if old can still be useful to the application.   We really
need to think about how to best arbitrate through different types of
backends.

Keith Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/geoclue/attachments/20070813/4d0d3942/attachment-0001.htm