<div class="gmail_quote">On Tue, Apr 19, 2011 at 7:27 AM, Michael Leibowitz <span dir="ltr"><<a href="mailto:michael.leibowitz@intel.com">michael.leibowitz@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On Mon, 2011-04-18 at 11:49 -0700, Eckhart Wörner wrote:<br> > Hi Michael,<br> ><br> > Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz:<br> </div>...<br> <div class="im">> > The GeoClue API/design is not terribly efficient. One ends up with<br> > > several round-trips around DBUS for any position information.<br> > > Additionally, using DBUS in this way leaks information all over the<br> > > place.<br> > ><br> > > [...]<br> ><br> > I take that as a complement for my proposal, since it doesn't enforce D-Bus<br> > usage between GeoClue2 and an individual provider anymore.<br> <br> </div>It was certainly not criticism of your proposal, but rather criticism of<br> GeoClue as it is now.<br> <div class="im"><br> > > The decision making powers and inputs to the Master Provider are too<br> > > simple to give optimal results. The master provider has no concept of<br> > > latency or power consumption, providers have no basis to specify them,<br> > > and clients have no basis to input their requirements for either.<br> > > Furthermore the resources that providers may request are too course<br> > > grained and rigid. For example, a satellite position provider might not<br> > > require network access to give information, but having it might enable<br> > > assistance that greatly reduces latency or increases accuracy.> The GeoClue<br> > API/design is not terribly efficient. One ends up with<br> > > several round-trips around DBUS for any position information.<br> > > Additionally, using DBUS in this way leaks information all over the<br> > > place.<br> ><br> > Why do you think an application knows better than GeoClue2 whether to use the<br> > network or how much power consumption is acceptable? If the application knows<br> > that the laptop is on battery, so does GeoClue2, if the application knows that<br> > there is an internet connection, so does GeoClue2. If there was any other<br> > essential piece of information which only the application has, there are<br> > probably some design issues in your stack somewhere else.<br> <br> </div>The application knows how long it plans to keep listening for location,<br> which GeoClue doesn't know. The application knows when it's willing to<br> trade accuracy, latency, or power consumption. </blockquote><div><br></div><div>I'd agree here that application knows what accuracy of position estimate it needs. Some need to determine just a country or state user currently is in, some need to remember position accurate to several meters (as in the example with parking place below). But I am not sure if it's right approach to let application to choose what providers to use. To me it seems correct if user has a possibility to choose in systems settings if network/GNSS/IP/etc positioning methods are allowed always/not allowed in roaming/prohibited and applications just get position fixes with accuracy estimate for each and decide if particular fix is suitable for their purposes ignoring the fix otherwise.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Simply using accuracy as<br> a proxy for power measurement doesn't give as much flexibility to choose<br> the lowest power mechanism. It also supposes that high accuracy methods<br> are always the least power efficient. This may not be true.<br> <br> Of course, I don't mean to imply that all this decision making power<br> needs to be directed from the application to GeoClue. Sometimes it is<br> just enhancing the interfaces from GeoClue to the underlying system that<br> would enhance its decision making powers. Knowing more than "the system<br> is connected to the internet" could be helpful. Mobile systems often<br> have power policies and connection policies that GeoClue could benefit<br> from interfacing to. Perhaps we can have facilities like these as more<br> flexible than they are currently to resemble position providers more.<br> <div class="im"><br> > > The abstraction of providers also hides provider details. This sounds<br> > > like the facts of life and a non-problem, but it actually is a problem.<br> > > There are my applications out there that want to display some detailed<br> > > status of their position fix but also want to be able to support several<br> > > positioning methods. For example, an application might want to report<br> > > the satellites in view if it's getting a GPS signal, but display the<br> > > access points it sees for a wifi based position method.<br> ><br> > Except that this information serves no purpose in normal applications which<br> > are just interested in position information. If you want to write an<br> > application that shows your full GPS information, you should connect to gpsd<br> > directly.<br> > (I have seen few people who actually know how to interpret satellite<br> > positions, which is a strong indicator that this is not something you want in<br> > your average application's interface.)<br> <br> </div>I disagree. I think that not only is this something that could be<br> trivially added, but isn't a niche thing. I've seen many a mobile<br> application that provide some information (useful or not) about their<br> positioning method. Additionally, the MeeGo API for location is the<br> Qt-Mobility Location API. It is designed to report satellite<br> information for satellite based fixes. At present, the implementation<br> has to talk to both GeoClue and Gypsy to get this information. This is<br> suboptimal and it doesn't have to be so awkward to do so.<br> <br> It doesn't mean that GeoClue should expose NMEA streams to clients or<br> that GeoClue should have lots of provider specific entanglements. But<br> would it be unreasonable for a provider to have a set of properties for<br> the current status of their underlying mechanism? The interpretation of<br> these properties needs not be codified. It could be as simple as an<br> array of string->value pairs that a provider can offer to clients.<br></blockquote><div><br></div><div>I agree here, including data structure proposal. The art will be to define standard string keys common to all provides. At the same time, I'd propose to move that from property of provide to property of position fix. Position fixes come in real time and when application asks a provider about its state, the state can change already from the one in which provider was generating a fix. </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > > How do you specify accuracy, latency, or power requirements? When<br> > > creating the objects? When querying them?<br> ><br> > Accuracy is specified as a property in the Provider object already.<br> > (There are some issues in the old API which IIRC freely mixes accuracy and<br> > precision).<br> <br> </div>Right. But I'm talking about the application side. An application<br> should be able to specify how accurate a fix it needs, how soon, and<br> perhaps some power trade-off information that it can give.<br> <br> For example, if you are creating a mapping application, you want to<br> start with the first available position from any source and as more<br> accurate sources become available, get better and better position.<br> <br> Consider another case, where you need to do drop a pin so you can<br> remember where you parked. Having information that is accurate to<br> within a few blocks is not helpful. It's not worth firing up a cell<br> tower triangulation system to give you position.<br></blockquote><div><br></div><div>Good examples. And I'd propose here to provide all necessary information to application (including accuracy) and let it decide if fix is useful or not. For example an application may use fixes that are not accurate enough to just show a position to show to the user that something is going on and then when accuracy gets good enough start turn-by-turn navigation. I just thing that we may end up with spending time adding a code that implements logic in GeoClue and then applications need to tell "give me all".</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> ><br> > I'm not sure latency is a good idea to add - how do you filter available data<br> > based on latency? How do you know there is less than 0.1 second delay in the<br> > bluetooth connection between your gps and your laptop?<br> <br> </div>But when you're in the process of resolving a position, you may start to<br> get an idea of latent it's going to be. For example, when you fire up<br> the GPS and you're not seeing satellites- you know it might be a while.<br> This could be useful information provided from the provider back to<br> GeoClue.<br></blockquote><div><br></div><div>Idea is good and that information would be useful probably. And problem is that GNSS receiver doesn't know that. It can be inside the building or other shielded environment and even having all ephemerides and accurate time it cannot predict when it makes first valid fix.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> > As already argued, GeoClue2 should have the same information about the power<br> > situation as the individual application, and can therefore make the same<br> > decisions.<br> ><br> > > I assume street is a freely encoded house number and street?<br> ><br> > I guess so. Address information has the same semantics as in the old GeoClue.<br> <br> </div>I would advocate a structured address personally. Getting this right<br> with locale and etc is not always trivial.<br> <div class="im"><br> > > Also, how<br> > > do you disambiguate ambiguous replies?<br> ><br> > I don't. This is a limitation I took over from the old API.<br> <br> </div>Might you reconsider?<br> <br> ...<br> <div class="im"><br> > > What is to be configured?<br> ><br> > The address of your bluetooth GPS, activated providers, the server that is<br> > used for cell triangulation, …<br> <br> </div>This sounds like GeoClue is storing provider information on behalf of<br> providers. Why should GeoClue get entangled with such things? In the<br> current case, it does because Gypsy has no configuration of its own. I<br> see this as a fault in Gypsy- not a reason for GeoClue be a grab-bag of<br> provider configuration information.<br></blockquote><div><br></div><div>Yes, I agree. That should be properties of provider. Btw, in theory we may have a provider that doesn't work with any HW, but gets data from other provides and makes some better fix available to applications. As GeoClue implements that 'provider plug-in' architecture it cannot no in advance what provider will be connected.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> Cheers<br> --<br> Michael Leibowitz <<a href="mailto:michael.leibowitz@intel.com">michael.leibowitz@intel.com</a>><br> <br> _______________________________________________<br> </div><div><div></div><div class="h5">GeoClue mailing list<br> <a href="mailto:GeoClue@lists.freedesktop.org">GeoClue@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/geoclue" target="_blank">http://lists.freedesktop.org/mailman/listinfo/geoclue</a><br> </div></div></blockquote></div><br clear="all">Best regards,<br>Roman Gezikov.<br><br><br>