Re: [PATCH 0/2] iw: add GeoClue support

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2010-08-20 at 20:29 -0400, Luis R. Rodriguez wrote:
>> This series adds GeoClue support to iw.
>
> Quite frankly, I don't see the point?

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.

I'll explain some more below.

> What use is a command line tool that has to talk to a whole bunch of
> daemons etc.?

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
would simply be a cached response.

> I could see using say NM to connect it all,

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 GeoClue depends on
Glib and Dbus so there are also size considerations embedded
distributions must make if they are not supporting Glib and/or Dbus.

For distributions then the question of the master provider and
overhead library support remains. The iw patch I provide simply
provides an example of how to do this in userspace applications and I
would like to expand on it to use other providers first like Gpysy and
Gpsd until the desktop catches up. This may mean we end up handling
this in wpa_supplicant -- not sure, this would be a good time to
review this or we can also review this at the upcoming summit. For
embedded distributions like openwrt it also provides a sample of what
can be equivalently done, I doubt Glib support will be integrated.

> or maybe put it into geoclue directly,

GeoClue provides clients an API to query geolocation information. Its
up to the different distributions to decide if they want to implement
support for the master provider, which providers they want to handle.
Client software then just queries GeoClue, what we need then is
different userspace clients being capable of querying this information
if GeoClue is supported to send it off to the kernel.

> but a command line to trigger it all seems
> like a wrong approach?

Its an option which can be made available to distributions, right now
we have no other except a set of bash scripts to for example query
timezone and things like that. Piggy backing this on top of iw lets
distributions eventually replace those scripts with a simple iw call.
That should also get distributions to consider implementing the master
GeoClue provider.

The last mile IMHO, will be to figure out how the different desktops /
connection managers like Network Manager and Connman, and embedded
systems ultimately use some of this or use alternatives.

 Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> 
> > What use is a command line tool that has to talk to a whole bunch of
> > daemons etc.?
> 
> 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
> would simply be a cached response. 

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

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > 
> > > What use is a command line tool that has to talk to a whole bunch of
> > > daemons etc.?
> > 
> > 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
> > would simply be a cached response. 
> 
> 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 see, can you elaborate on that a little?

> 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.

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

  Luis

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 10:46 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> > On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > > 
> > > > What use is a command line tool that has to talk to a whole bunch of
> > > > daemons etc.?
> > > 
> > > 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
> > > would simply be a cached response. 
> > 
> > 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 see, can you elaborate on that a little?

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

> > 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.
> 
> Would the master provider not use Dbus for gypsy, for example?

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]

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 10:46 -0700, Luis R. Rodriguez wrote:
> > On Mon, Aug 23, 2010 at 09:05:07AM -0700, Bastien Nocera wrote:
> > > On Mon, 2010-08-23 at 08:44 -0700, Luis R. Rodriguez wrote:
> > > > 
> > > > > What use is a command line tool that has to talk to a whole bunch of
> > > > > daemons etc.?
> > > > 
> > > > 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
> > > > would simply be a cached response. 
> > > 
> > > 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 see, can you elaborate on that a little?
> 
> See the bugzillas filed against Geoclue, most of them are due to bugs in
> the Geoclue master provider.
> 
> > > 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.
> > 
> > Would the master provider not use Dbus for gypsy, for example?
> 
> 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]

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

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
<snip>
> > 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]
> 
> 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?

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

Re: [PATCH 0/2] iw: add GeoClue support

[Luis R. Rodriguez]

On Mon, Aug 23, 2010 at 03:15:07PM -0700, Bastien Nocera wrote:
> On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> > On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> <snip>
> > > 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]
> > 
> > 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?
> 
> Exactly, and it's mentioned in the bugzilla

Thanks for the heads up, I haven't been grep'ing through the bugzilla.

> and was discussed on the mailing-list as well.

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

Re: [PATCH 0/2] iw: add GeoClue support

[Bastien Nocera]

On Mon, 2010-08-23 at 15:22 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 23, 2010 at 03:15:07PM -0700, Bastien Nocera wrote:
> > On Mon, 2010-08-23 at 15:11 -0700, Luis R. Rodriguez wrote:
> > > On Mon, Aug 23, 2010 at 02:05:56PM -0700, Bastien Nocera wrote:
> > <snip>
> > > > 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]
> > > 
> > > 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?
> > 
> > Exactly, and it's mentioned in the bugzilla
> 
> Thanks for the heads up, I haven't been grep'ing through the bugzilla.
> 
> > and was discussed on the mailing-list as well.
> 
> 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.

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