On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg

To help us move forward to automate location awareness information
into the kernel. I don't think we can unify all possible solutions for
the different distributions out there so best is to make available
whatever utilities we can and allow the distribution implementors to
embrace whatever they want.


The current implementation doesn't talk to deamons. The hostip
provider within GeoClue and it will just trigger a URL get. If
desktops start implementing a master server though then the query

GeoClue has some initial connectivity support now. It allows your
connectivity managers to provide back things like status of your
connection, your AP's MAC address, router MAC address, and a list of
APs. The last one can be used by Plazes and Skyhook for example.
GeoClue now supports this connection interface with Network Manager
and as of recently for Connman. Technically Connman and Network
Manager then can seed GeoClue with bits of info for providers. For
example I can forsee a GeoClue http://wigle.net provider implemented
where the provider can make use of the existing connection manager
services to query APs and eventually provide clients its location.

So clients are the ones querying GeoClue, and its up to them to
implement support. Network Manager and Connman can add support for
GeoClue by doing a similar query but then the question arises if all
distributions will also be providing a master provider. The GeoClue
master provider caches queries based on all supported and available
providers so that clients do not have to wait for a provider to do its
work on an independent query. If not master provider is installed on a
system, each GeoClue client will have to poke at the respective
provider to do its own work. In the case of the hostip provider a
simple URL query is made and parsed (http://api.hostip.info). For
other providers like gypsy Dbus will be used to get gypsy to do its
thing and give back information. I should also note ...
[ message continues ]

Note that this error carries on in the mail. There is a master provider
for Geoclue that can make use of whatever providers are available, but
it's not in too good a shape.

I'd rather somebody started fixing the Geoclue master provider rather
than relying on a particular service, especially when the D-Bus API for
the providers themselves is something we don't want to support in the
longer term.

Cheers

--

[ message continues ]

Would the master provider not use Dbus for gypsy, for example?

  Luis
--

[ message continues ]

See the bugzillas filed against Geoclue, most of them are due to bugs in

No, I'm talking about what's exported by the providers. I don't really
care if they talk to other parts of the system using D-Bus though. I'm
talking about link 2) here.

[App] <-1-> [Geoclue master] <-2-> [Gypsy provider] <-3-> [Gypsy daemon]

--

[ message continues ]

Sorry I do not follow yet. Is the idea that you would prefer if
client applications would never talk to providers directly and instead
always used the master provider?

 Luis
--

[ message continues ]

Exactly, and it's mentioned in the bugzilla, and was discussed on the
mailing-list as well.

--

[ message continues ]

And am new there :)

This makes sense -- are there plans on removing all these exported
library routines so that the only exposed thing is the master
provider calls?

Based on your comments it seems changing the iw patch to just
use the master provider would go more in line with current
development focus.

  Luis
--

[ message continues ]

Right. And file bugs if you have specific uses that don't work as
expected with the master provider.

--

[ message continues ]