RFC: How to decide which backend(s) to use

[Andrew Turner]

On 6/20/07, keith preston <keithpre at gmail.com> wrote:
> This is a really difficult question.   One that I didn't know how to do.
> Originally, I had planned on accuracy as the defining point.    Each backend
> would signal a master process about it's accuracy and when it got more
> accurate.   From this the clients would chnge over to the more accurate
> backends.

I agree with your comments. I think the first version (and maybe
always) of GeoClue is rather 'thin'. Don't put too much into it, or it
becomes too specialized to use for generic apps or difficult to
maintain. :)


>
>
> I thought this would suffice, but the civic location idea does bring up
> problems.   What if different backends implement different methods?   I
> still vote for allowing more control from the programmers, but maybe
> providing examples on how to change between providers and such.
>
> Keith Preston
>
>
> On 6/19/07, Jussi Kukkonen <jhkukkon at cc.hut.fi> wrote:
> >
> > 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
> >
> >
> > _______________________________________________
> > GeoClue mailing list
> > GeoClue at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/geoclue
> >
> >
> >
>
>
> _______________________________________________
> GeoClue mailing list
> GeoClue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/geoclue
>
>


-- 
Andrew Turner
ajturner at highearthorbit.com      42.2774N x 83.7611W
http://highearthorbit.com              Ann Arbor, Michigan, USA