new method/signal suggestions

[Jussi Kukkonen]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20070811/28f7a550/attachment.pgp