[FOSS-GPS] Re: FoxtrotGPS/libgps w/ fso-gpsd

[Joshua Judson Rosen]

Timo Juhani Lindfors <timo.lindfors at iki.fi> writes:
>
> James Hiebert <james at hiebert.name> writes:
> > On Fri, Oct 15, 2010 at 08:47:16AM +0300, Timo Juhani Lindfors wrote:
> > > Would an alternative be to have ogpsd feed nmea or ubx to real gpsd?
> >
> > Well on my Freerunner, ogpsd gets UBX packets from the ogpsd.gpsdevice. 
> > Seems like it'd be relatively straightforward to just pass them through, if
> > esr-gpsd can consume them.
> 
> gpsd can consume UBX at least here yes.
> 
> > This seems like a bad idea, though.  I would assume that the gpsd
> > layer is there for a reason... mostly so that the application can be
> > insulated from gps and hardware specific issues.  Such an argument
> > is addressed here:
> > http://gpsd.berlios.de/faq.html#why_not_parse_nmea
> 
> I am not sure what you mean. Applications that use gpsd do not see UBX
> even though gpsd reads UBX. They are insulated from hardware specific
> details.
> 
> > http://gypsy.freedesktop.org/why-not-gpsd.html
> > my understanding is that if we wrote a dbus interface for foxtrot,
> > fox could just register for the signals and then sleep between
> > updates, conserving the battery.

I'm not so sure that there's actually an opportunity to sleep
like this that we're not already taking....

> But is gypsy the right protocol?

As far as I can tell, probably not:

> I understood that it was never in any distro and its development has
> slowed down.

Right. And, to balance out Gypsy's `Why Not GPSD', there's
also `Why You Should use GPSD over Gypsy':

    http://gpsd.berlios.de/gypsy.html


And, of course, FSO isn't even actually using Gypsy--
frameworkd just implements its own Gypsy-alike
D-Bus API; and the Gypsy D-Bus API itself doesn't
get you power-management: you need to support
the Gypsy API + a FSO-specific resource-management API.

Just from the perspective of maintainability,
I'd really prefer to avoid supporting 3 different APIs
if I can just support one; globally, the idea of
every GPS app having to simultaneously support 3
(or more?) different GPS APIs directly sounds
even worse. Really, as a community, we ideally want
a single cohesive API that we can just use, so that
we don't all end up writing the same code, right?

Ultimately, I think what's going to happen here is that
gpsd is going to continue fleshing-out its feature-set,
so that it supports things like power-management
(there are people working toward this, right now), and
also supports every piece of GPS hardware under the sun
(actually, it looks like this is already the case...).

In the mean time, though, there's probably going to be some pain;
the reason that I suggest fixing fso-gpsd is that, while it's
not a long-term solution, it should basically be the smallest amount
of work and provide the most benefit to the most people in the shortest
amount of time; in particular, while I can't speak for Debian or any
of the Debian maintainers, I'd be extremely surprised if anything
more drastic made it into the upcoming release (Squeeze/6.0);
but `make fso-gpsd actually support a non-deprecated gpsd protocol'?
Maybe.

> On modern desktop environments you nowadays see geoclue
> dbus api instead,
> 
> http://geoclue.freedesktop.org/

Yes--GeoClue looks interesting; Guilhem Bonnefille brought it up,
a few months back, and we had some brief discussion about it.
If someone wants to look into using it, that would be great.

One question I have, regarding GeoClue, is whether
we'd be able to switch over to *just* using GeoClue without
losing support for connecting to remote gpsd instances--
I occasionally run FoxtrotGPS on my laptop connected
via a TCP socket to a GPSD instance running on my phone,
and probably there are other people who do things like that....

Do you know whether that would work with GeoClue?

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."