Re: MM Location API and MBM GPS

[Dan Williams <dcbw redhat com>]

On Tue, 2010-09-07 at 21:06 +0100, Sjoerd Simons wrote:
> On Tue, 2010-09-07 at 17:38 +0100, Bastien Nocera wrote:
> > On Sun, 2010-09-05 at 15:15 +0100, Sjoerd Simons wrote:
> > > Comments, suggestions, flames ? :)
> > 
> > Dan, rightly so, didn't like the idea of just handing out a socket to
> > Gypsy. There are multiple reasons for that:
> > - you want MM to still have complete control over the ports offered
> 
> reasonable point, in this case the port isn't used by MM for any of its
> functionality so handing it out to an accomplish isn't so bad.

We could do MBM GPS in MM, but we also don't have to since the device
has enough serial ports to handle it.  The MM support is mostly there
for devices which need a bunch of setup or where the modem only exposes
2 serial ports, both of which MM needs to claim.

> > - it would make it hard to push vendor specific hacks to Gypsy
> 
> I don't understand what you mean here.
> 
> > - a lot of modems don't actually give you NMEA data at all, so it
> > wouldn't make sense to parse the proprietary format, put it into NMEA,
> > just to have it parsed again
> 
> Well sure, this wouldn't be something that suitable for all modems (i
> never said it would be a general mechanism). But the specific modem i'm
> looking at (which is quite common) does actually have a real actual full
> GPS hidden in its guts, you just have to poke it a bit so it comes out
> of hiding.
> 
> It seems pointless to re-implement the functionality to read an NMEA
> stream out of a serial port when we already have Gypsy that does this
> nicely for us (and parses it and exposes it over dbus etc). 
> 
> One could go for a middle ground where MM reads from the serial device
> and passed the nmea stream over a unix socket or whatever to Gypsy.
> (This means MM is in full control, we don't cause loads of dbus traffic
> and we can let Gypsy do what it's good at).

That's sort of the approach I was taking with the NMEA method of the MM
Location API thusfar.  Again it's not as much of an issue for MBM
devices, but MM could serve as a proxy (authenticated with PolicyKit
even) for this information.  Or not.

But since I have some MBM devices I'll probably end up adding the MBM
NMEA support to MM anyway unless somebody gets there first...

Dan

> > The right way to implement this would be through a Geoclue provider,
> > which you could hit directly from your application if you're so
> > enclined, or just let it be one more provider amongst others.
> 
> A Geoclue provider is great and all (oh look there is already one for
> gypsy :p), but it doesn't expose all the information you get from a GPS.
> And neither should it, things like satelite position and signal quality
> will only ever be useful in the context of GPS. So abstracting that in
> geoclue doesn't make much sense to me, Gypsy already has those
> abstractions for us so we should just use them.
>