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. 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). -jussi
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
