RFC: How to decide which backend(s) to use
Jussi Kukkonen
jhkukkon at cc.hut.fi
Tue Jun 19 15:14:54 PDT 2007
This RFC is actually somewhat related to the earlier (hopefully even
ongoing) discussion on interfaces.
Selecting the backend to use is not just a matter of choosing the
default one, if we want to do it right. Example: Let's say the user has
the following position backends installed
1. GPS
2. Hostip
Scenario 1. Application wants to know the city/country (assume civic
location is now included in the position-interface).
Scenario 2: An application wants coordinates. User does not have a GPS
device with her (or she is indoors).
In both scenarios the default GPS backend is unusable. Problem in
scenario 1 is something that could be avoided with having separate
interfaces for civic/coordinate location, but that is just a special
case. Scenario 2, and many other situations like it, would require the
application to call get_all_position_providers() and try another backend
if the current_position()-method of the first backend failed... This is
not friendly at all.
Conclusions/questions:
* There should be an order of preference for backends
(a list in gconf instead of just the default backend?)
* Getting information from the several backends should be as seamless as
possible. I don't see why we couldn't totally abstract this in the
bindings / wrapper library?
If a method (e.g. current_position()) fails, and
if no backend was initialized with generic init-method and
if there are backends still left on the list of backends
Initialize the next backend in the list and
call the current_position method() on the new backend
Is there something seriously wrong with this idea? If it works,
applications could just say
"I want [Coordinates|City Name|Street Address|...]"
and get that information without knowing any details.
-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/20070620/11e05a22/attachment.pgp
More information about the GeoClue
mailing list