<div>On 8/11/07, Jussi Kukkonen <<a href="mailto:jhkukkon@cc.hut.fi">jhkukkon@cc.hut.fi</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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).</blockquote><div> 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 </div> </div>