Looking at the API

[Jussi Kukkonen]

Hi Keith,

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

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>
>>
>>     <method name="GetStatus" />
>>     <signal name="StatusChanged" />
>>     <method name="Shutdown" />
>> </interface>
>>
> 
> 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
might not.


[On Address-inteface:]
> 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.


[On Accuracy-interface:]
> 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.


-jussi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/geoclue/attachments/20071110/0166b69a/attachment.pgp