On Mon, Aug 23, 2010 at 7:11 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
