On 8/11/07, Jussi Kukkonen <[EMAIL PROTECTED]> 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
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
