On Mon, 2011-04-18 at 11:49 -0700, Eckhart Wörner wrote: > Hi Michael, > > Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz: ... > > 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.
It was certainly not criticism of your proposal, but rather criticism of GeoClue as it is now. > > 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 application knows how long it plans to keep listening for location, which GeoClue doesn't know. The application knows when it's willing to trade accuracy, latency, or power consumption. Simply using accuracy as a proxy for power measurement doesn't give as much flexibility to choose the lowest power mechanism. It also supposes that high accuracy methods are always the least power efficient. This may not be true. Of course, I don't mean to imply that all this decision making power needs to be directed from the application to GeoClue. Sometimes it is just enhancing the interfaces from GeoClue to the underlying system that would enhance its decision making powers. Knowing more than "the system is connected to the internet" could be helpful. Mobile systems often have power policies and connection policies that GeoClue could benefit from interfacing to. Perhaps we can have facilities like these as more flexible than they are currently to resemble position providers more. > > 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.) I disagree. I think that not only is this something that could be trivially added, but isn't a niche thing. I've seen many a mobile application that provide some information (useful or not) about their positioning method. Additionally, the MeeGo API for location is the Qt-Mobility Location API. It is designed to report satellite information for satellite based fixes. At present, the implementation has to talk to both GeoClue and Gypsy to get this information. This is suboptimal and it doesn't have to be so awkward to do so. It doesn't mean that GeoClue should expose NMEA streams to clients or that GeoClue should have lots of provider specific entanglements. But would it be unreasonable for a provider to have a set of properties for the current status of their underlying mechanism? The interpretation of these properties needs not be codified. It could be as simple as an array of string->value pairs that a provider can offer to clients. > > 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). Right. But I'm talking about the application side. An application should be able to specify how accurate a fix it needs, how soon, and perhaps some power trade-off information that it can give. For example, if you are creating a mapping application, you want to start with the first available position from any source and as more accurate sources become available, get better and better position. Consider another case, where you need to do drop a pin so you can remember where you parked. Having information that is accurate to within a few blocks is not helpful. It's not worth firing up a cell tower triangulation system to give you position. > > 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? But when you're in the process of resolving a position, you may start to get an idea of latent it's going to be. For example, when you fire up the GPS and you're not seeing satellites- you know it might be a while. This could be useful information provided from the provider back to GeoClue. > 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. I would advocate a structured address personally. Getting this right with locale and etc is not always trivial. > > Also, how > > do you disambiguate ambiguous replies? > > I don't. This is a limitation I took over from the old API. Might you reconsider? ... > > What is to be configured? > > The address of your bluetooth GPS, activated providers, the server that is > used for cell triangulation, … This sounds like GeoClue is storing provider information on behalf of providers. Why should GeoClue get entangled with such things? In the current case, it does because Gypsy has no configuration of its own. I see this as a fault in Gypsy- not a reason for GeoClue be a grab-bag of provider configuration information. Cheers -- Michael Leibowitz <[email protected]> _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
