Looking at the API
jku at o-hand.com
Sat Nov 10 10:21:31 PST 2007
Nice to hear you didn't take offence on us ripping everything open :)
We didn't actually intend to do that. It's just that after a few really
crucial changes it was obvious that important parts of the API were
going to break anyway. At that point we couldn't _not_ fix the small
IMO what we have so far is pretty good and the changes are worth it. At
least the proposal API would have made my life a lot easier when I was
writing the Maemo UI...
keith preston wrote:
>> <interface name="org.freedesktop.Geoclue">
>> <property name="ServiceName" type="s" access="read"/>
>> <method name="GetVersion">
>> <arg name="major" type="i" direction="out" />
>> <arg name="minor" type="i" direction="out" />
>> <arg name="micro" type="i" direction="out" />
>> <method name="GetStatus" />
>> <signal name="StatusChanged" />
>> <method name="Shutdown" />
> I still like the idea of services providing certain level of Human
> readable strings. Here we have ServiceName, but I think we could
> also have ServiceDescription. A longer version so that people can
> understand how their computer knows where they are.
I was thinking about the same thing this week. This might be handy for a
Geoclue preferences UI (or just a client that wants to expose some
details to user). Could be that it never gets used, but the cost of
implementation is so low that I support this.
>> We're not sure yet how best to do GetStatus and StatusChanged. The
>> thinking behind it is that the master process would be able to use that
>> to check if a backend can currently be used, IE a GPS backend's status
>> would indicate that it cannot be used if the GPS device isn't connected,
>> or a backend that requires network access would indicate that it cannot
>> be used if the network has disappeared.
>> The main problem with this is that it would require backends to have a
>> lot of complex logic and maybe have a lot more dependencies
>> (network-manager for knowledge about networks, but then we have the
>> problem of what to do when network-manager isn't used.) This may just be
>> more trouble than its worth, but we think we'll know more about the
>> requirements when we come to do the master process which is why we left
>> them in for the time being.
> I don't think that it would require a lot of complex knowledge. You
> can make your backend as smart as you want based on the dependencies
> it need. We just provide clean interfaces.
Ensuring that backends actually provide the status-signal may be hard or
impossible, but I'm hoping there won't be that many real world problems:
If a backend is typically unavailable often, it probably will have
availablity-signals -- as an example most mobile devices will have a
NetworkManager/libconic-type implementation, even if desktop machines
> I think we should also provide a separate method for fuzzy logic
> search. Where the application can provide 1 text string and it
> returns an lat lon. (Like google)
Good catch, I somehow just forgot that when we were trying to get the
accuracy stuff usable... We'll get back to you on this one once we have
it thought out.
> Hmmm.... I don't think this is bad, but here's how I would implement
> it. First of all you probably want 3d accuracy and not 2d accuracy.
I just can't see three accuracy values (latitude_accuracy,
longitude_accuracy and vertical_accuracy) being
a) available from any data source
b) useful for something
Do you have an example use case for this?
> Secondly, I would have the interface give raw meters and then put
> convenience methods on both sides of the api for using these meta
> fuzzy enums. The enums would define ranges in meters.
> getAccurracy(&hor, &ver, & alt)
> GEOCLUE_ACCURACY accuracy = meta_accuracy(hor, ver)
> if(accuracy == GEOCLUE_ACCURACY_LEVEL_COUNTRY)
Iain referred to a long discussion on accuracy: you just found it :)
Iains point, if I remember it correctly, was that using just meters
would lose information as the user may have additional context that the
backend does not have: Imagine a user locating herself with an
Address-based backend (say, hostip). She knows that
"accuracy=CITY_LEVEL" means about 1km because she happens to be in a
small town, not Mexico City...
I'd be fine with just meters, even though I had to admit that the above
might happen in real world.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20071110/0166b69a/attachment.pgp
More information about the GeoClue