GeoClue2

[Bastien Nocera]

On Sun, 2011-04-17 at 17:49 +0200, Eckhart Wörner wrote:
> Hi everybody,
> 
> when I first encountered GeoClue some time ago, I immediately liked the idea of 
> it. However, I was somehow never really satisfied with its design. Therefore, 
> in the last few days I tried to write down my vision of how its D-Bus API 
> should look like, and now present it here for discussion. I'll start with the 
> problems the old API has in my eyes, and then present a new API that hopefully 
> overcomes these problems.
> 
> I'll call the old API GeoClue and my API GeoClue2 only to differentiate between 
> them, not because I think that my API is perfect (it probably isn't). It also 
> probably helps my subject getting some attention. ;-)
> 
> 
> == Problems ==
> 
> The GeoClue API is incomplete: GeoClue Position and Velocity provide the 
> coordinates of a point (which normally represents a device so close to the 
> user's coordinates that we define them to be the user's coordinates) in a 
> three-dimensional room (Latitude, Longitude, 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.

> The GeoClue API defines several providers and puts arbitrary borders between 
> them: Latitude, Longitude and Altitude share the same provider, while Speed, 
> Direction and Climb share a different provider, however, e.g. an altimeter only 
> provides Altitude and Climb.

Again, that could probably be done within a provider.

> The GeoClue API is overly complex in some places: to get latitude, longitude 
> and speed, one has to traverse two objects, and then use two different 
> providers.

You're talking syntactic sugar here.

> The GeoClue API exposes too much information to an application that uses it: 
> an application that relies on the *type* of the underlying provider clearly 
> does something wrong. An application should not decide which provider to use, 
> instead GeoClue2 should. An application should not configure providers, a 
> dedicated interface should do that.

Agreed. But the fact that the master provider was so broken made it
impossible to use.

> The GeoClue API does not differentiate between an application that needs some 
> piece of information to work properly, and a piece of information that is 
> nice-to-have, but not necessary. E.g. an application for navigation clearly 
> needs coordinates to work properly, while a weather applet that works fine 
> without coordinates might still use them when they are available.
> 
> 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.

> The GeoClue API does not cope well with unexpected application behavior like 
> crashes. E.g. AddReference and RemoveReference are just asking for problems.
> 
> 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?

> == Proposal ==
> 
> The GeoClue2 service is the only access point to information; there's no 
> documented way of communicating with individual providers for information 
> retrieval.
> 
> The main interface allows to create objects for individual applications. Any 
> object created through the main interface is said to be owned by the 
> respective application and should not be used by any other application.
> 
> This is the main interface:
> 
> <node>
> 	<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.

> 		<method name="CreateAddressResolver">
> 			<arg name="path" type="o" direction="out" />
> 		</method>
> 
> 		<method name="CreateCoordinatesResolver">
> 			<arg name="path" type="o" direction="out" />
> 		</method>
> 
> 	</interface>
> </node>
<heavy snip>

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.

> The Provider (yes, I know this is not the best name) is responsible for 
> providing information about aspects of the position of the device. These 
> include:
> - 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).
<snip>
> 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).

Cheers