RE: MM Location API and MBM GPS
- From: Dan Williams <dcbw redhat com>
- To: Torgny Johansson <torgny johansson ericsson com>
- Cc: "networkmanager-list gnome org" <networkmanager-list gnome org>
- Subject: RE: MM Location API and MBM GPS
- Date: Mon, 20 Sep 2010 17:34:48 -0500
On Wed, 2010-09-15 at 14:15 +0200, Torgny Johansson wrote:
> > -----Original Message-----
> > From: networkmanager-list-bounces gnome org
> > [mailto:networkmanager-list-bounces gnome org] On Behalf Of
> > Dan Williams
> > Sent: den 15 september 2010 07:58
> > To: Sjoerd Simons
> > Cc: networkmanager-list gnome org
> > Subject: Re: MM Location API and MBM GPS
> > 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.
> Right, but even if we do add it, MM won't claim the second port for NMEA data unless explicity told to, right? It won't occupy it if noone has registered for location data?
For MBM specifically right now, I dont' think MM will really claim more
than one port, because the data port is the netdevice. So MM only needs
one port for command & status. But if we did implement mbm location
services natively in ModemManager, we'd probably want to pick up a
> > > > - 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...
> I have been looking at it briefly but atleast right now I won't have time
> to do it unfortunately. I am interested in this though and will do what I can to help.
> Btw, how do you see this will be used? By feeding data to geoclue, gpsd/gypsy, mapping applications (or browsers) directly or any of those?
] [Thread Prev