GeoClue2

[Bastien Nocera]

On Mon, 2011-04-18 at 21:45 +0200, Eckhart Wörner wrote:
> Hi Bastien,
> 
> Am Montag, 18. April 2011, 14:45:36 schrieb Bastien Nocera:
> > > Altitude), and the first derivative (Speed, Direction, Climb). However,
> > > we still don't know the orientation of the device in this room.
> > > Why may this information be useful? E.g. a routing application for
> > > pedestrians can rotate the map it displays according to the heading of
> > > the device.
> > 
> > I don't think anyone can say it's not useful. But it wouldn't come from
> > the same hardware device. The gypsy or gpsd providers should probably
> > combine their results with the data from the altimeter if it's a
> > separate piece of equipment.
> 
> You're talking about the actual implementation here.

Yes, because I don't think we should be advertising what hardware
actually gets used.

> > Agreed. But the fact that the master provider was so broken made it
> > impossible to use.
> 
> That's why in my design there's *only* the master provider, which should 
> ensure it's actually working. No way to work around it.

Completely agreed here.

> > > Applications may be interested in the last known value for some piece of
> > > information, even though it is not valid anymore.
> > 
> > We should have timestamps for the various events given to applications.
> > That would solve that particular problem.
> 
> I don't see why that would solve the problem.

When sending out position information, the application would know that
the data is outdated by seeing that the timestamps are older than its
own request.

> > > The GeoClue API does not play well with D-Bus: Long-running methods will
> > > break as D-Bus puts a timeout on method calls.
> > 
> > Which methods did you see that were long-running?
> 
> AddressToPosition and PositionToAddress are both functions that could easily 
> take over a minute (consider a flaky mobile broadband connection), after 30 
> seconds the D-Bus timeout already kicks in. (And no, increasing the D-Bus 
> timeout is never an option)

Right. Both of those should be in a separate library, and I've
implemented a small library on top of Yahoo!'s Place Finder API to
remove the geocoding/rev geocoding problem from Geoclue.

> > > 	<interface name="org.freedesktop.Geoclue2">
> > > 	
> > > 		<method name="CreateProvider">
> > > 		
> > > 			<arg name="path" type="o" direction="out" />
> > > 		
> > > 		</method>
> > 
> > That method doesn't seem to allow for errors.
> 
> Unless you're OOM, CreateProvider should never error out.

Right.

> > There's no privacy concerns with address to geocode, or geocode to
> > address resolutions. I think this should be implemented as a library,
> > instead of trying to add to the confusion by running it in a D-Bus
> > service.
> 
> Yeah, maybe. I mainly added it because it already had been in GeoClue.

Let's not discuss those any more, I believe everyone agree that we
shouldn't have this in Geoclue itself.

> > > - CountryCode, Country, Region, Locality, Area, PostalCode, Street
> > 
> > Where would those come from? I really don't think we want to pass those
> > out from the provider, except as extra metadata, and certainly not in
> > that format (we mentioned using a hashtable of string keys and values
> > for this in the past).
> 
> You do realize GeoClue has this already defined?
> (http://folks.o-hand.com/jku/geoclue-docs/Address.html)

And it was broken in Geoclue :)

> Also, if you look at the implementation of D-Bus properties you'll realize 
> that properties aren't that different from the current implementation: D-Bus 
> uses a{sv} for properties, GeoClue uses a{ss}. I think making GeoClue2 rely on 
> D-Bus standards as much as possible is the way forward.

There's no easy ways to update batches of properties, and have them all
be updated in one go. You would also still get that same problem you had
with have to traverse multiple objects, or make multiple D-Bus calls to
get information you're interested in.

> > > An application indicates that it needs one or more properties to
> > > function
> > > correctly by setting ActiveProperties to the corresponding property
> > > names.
> > 
> > I really don't think using properties is an effective way to pass this
> > information along to applications. It's missing all sorts of interesting
> > metadata (such as when the data was captured).
> 
> Again, there is no regression compared to old GeoClue.

Well, we're redesigning because the old Geoclue wasn't good enough...

> The PropertiesChanged signal fires when new data is available, in the same way 
> PositionChanged, VelocityChanged, AddressChanged fired before. The 
> PropertiesChanged signal transports the values for all properties that have 
> changed, so no extra roundtrip.
> 
> Also, every aspect of the data may have been captured at a different time. This 
> would mean there's a LatitudeTimestamp, AltitudeTimestamp, HeadingTimestamp, 
> SpeedTimestamp, ElevationTimestamp, … That's why I'm uncomfortable with the 
> idea of timestamps.

I think we should have separate APIs to deal with compasses and
altimeters. FWIW, nobody replied to my request for hardware for
altimeters and compasses. I'd really like to know whether those would be
separate discrete pieces of hardware, or be integrated into something
like a GPS itself, which would give us a single source of information.

> If you think it's unrealistic that these aspects all come from different 
> sources, think about a car: there's the gps, there are sensors which measure 
> speed, other sensors that measure elevation, there is an integrated compass, 
> etc.
> (GeoClue2 should of course not be used for controlling airbags ;-) )

Well, for such cars, you'd probably write your "Geoclue2" plugin to
control all those, and disable the network providers, for example. You
also wouldn't have the same requirements as in a phone where battery
life is at a premium.

Cheers