[PATCH 0/2] iw: add GeoClue support

Luis R. Rodriguez lrodriguez at atheros.com
Mon Aug 23 15:11:19 PDT 2010


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


More information about the GeoClue mailing list