Hi Michael, Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz: > You beat me to the punch. I was about to write a similar email > discussing a geoclue redesign. ;)
I won. ;-) > The GeoClue API/design is not terribly efficient. One ends up with > several round-trips around DBUS for any position information. > Additionally, using DBUS in this way leaks information all over the > place. > > [...] I take that as a complement for my proposal, since it doesn't enforce D-Bus usage between GeoClue2 and an individual provider anymore. > The decision making powers and inputs to the Master Provider are too > simple to give optimal results. The master provider has no concept of > latency or power consumption, providers have no basis to specify them, > and clients have no basis to input their requirements for either. > Furthermore the resources that providers may request are too course > grained and rigid. For example, a satellite position provider might not > require network access to give information, but having it might enable > assistance that greatly reduces latency or increases accuracy.> The GeoClue API/design is not terribly efficient. One ends up with > several round-trips around DBUS for any position information. > Additionally, using DBUS in this way leaks information all over the > place. Why do you think an application knows better than GeoClue2 whether to use the network or how much power consumption is acceptable? If the application knows that the laptop is on battery, so does GeoClue2, if the application knows that there is an internet connection, so does GeoClue2. If there was any other essential piece of information which only the application has, there are probably some design issues in your stack somewhere else. > The abstraction of providers also hides provider details. This sounds > like the facts of life and a non-problem, but it actually is a problem. > There are my applications out there that want to display some detailed > status of their position fix but also want to be able to support several > positioning methods. For example, an application might want to report > the satellites in view if it's getting a GPS signal, but display the > access points it sees for a wifi based position method. Except that this information serves no purpose in normal applications which are just interested in position information. If you want to write an application that shows your full GPS information, you should connect to gpsd directly. (I have seen few people who actually know how to interpret satellite positions, which is a strong indicator that this is not something you want in your average application's interface.) > How do you specify accuracy, latency, or power requirements? When > creating the objects? When querying them? Accuracy is specified as a property in the Provider object already. (There are some issues in the old API which IIRC freely mixes accuracy and precision). I'm not sure latency is a good idea to add - how do you filter available data based on latency? How do you know there is less than 0.1 second delay in the bluetooth connection between your gps and your laptop? As already argued, GeoClue2 should have the same information about the power situation as the individual application, and can therefore make the same decisions. > I assume street is a freely encoded house number and street? I guess so. Address information has the same semantics as in the old GeoClue. > Also, how > do you disambiguate ambiguous replies? I don't. This is a limitation I took over from the old API. > > Communication of changes is done via the standardized PropertiesChanged > > signal. > > What if I'm not interested if some of the properties change? I don't > want to be woken up if the compass changes and I don't care about the > compass. Might I suggest a more fine-grained approach of specifying > requirements for change notification as well? If Heading is neither in ActiveProperties nor in PassiveProperties, the property won't be set by GeoClue2 at all (and hence the PropertiesChanged signal will never be emitted for it either). The Provider only has a limited view on the information available, where the limitations are defined by ActiveProperties and PassiveProperties. > What is to be configured? The address of your bluetooth GPS, activated providers, the server that is used for cell triangulation, … Eckhart _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
