> > > There's a "valid_until" gconf-key that needs to be set to a value higher > than current time, or the backend won't emit the signals. I'm still open > to other, more generic solutions.
I think the valid until, is an interesting idea. I don't think it should stop emitting the position after the valid time, but rather have an significant increase in error. Todo list: > * Implement service_changed signal emission > * Add gconf schemas > * refactor (it's fairly rough right now, but I wanted it in so > Keith won't break my tree with more API changes :) > > Some observations about API changes: > * civic location method/signal should have timestamp argument too? > * I assume timestamp is time of original data retrieval, > in case of manual backend that would be when user inputs the data? > * Maybe current_position should actually work like "last_position": > always return the last valid position and let the client check if > timestamp is acceptable? If clients are interested in current data, > they should subscribe to signals anyway... The function should be > renamed though: "current" just doesn't describe this behaviour. This is an interesting idea. I believe this is what I intended with the timestamps. I believe the more we work with this, the more we find that multiple backends will be needed to find a good location. I believe timestamps will help us make the 'geoclue-master' arbitrator much easier. Keith Preston _______________________________________________ > GeoClue mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/geoclue > > >
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
