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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
