On Thursday 15 October 2009, Sander van Grieken wrote: > On Wednesday 14 October 2009 17:00:28 Philip Hands wrote: > > On Wed, Oct 14, 2009 at 11:59:24AM +0200, Michael 'Mickey' Lauer wrote: > > > Am Mittwoch, den 14.10.2009, 10:39 +0100 schrieb Al Johnson: > > > > On Wednesday 14 October 2009, Michael 'Mickey' Lauer wrote: > > > > > On a slightly related note (please open a seperate thread, if > > > > > anyone wants to talk about that), now that gypsy is more or less > > > > > dead and the protocol didn't find much distribution/acceptance, I > > > > > seriously consider proposing to ditch it for FSO2 and come up with > > > > > a sane GPS dbus API for fsogpsd (we talked about that last year on > > > > > this mailing list). Your work on a GPS configuration API could be > > > > > the first bits of the new style. > > > > > > > > If we're looking at a fresh API we should be looking at positioning > > > > in general. We have other sources of data such as cell lookup and > > > > magnetometers. In cars we may have access to speed data over CAN bus. > > > > We should provide some reasonably direct interface to each sensor > > > > available, plus a best estimate of position, orientation and velocity > > > > bsed on the available data. > > > > > > True, however I see this as seperate layer above GPS, which projects > > > like geoclue work on as well. I always like to provide multiple layers > > > of abstraction for application programmers to chose, this approach is > > > manifested by things like org.freesmartphone.GSM (lowlevel) -> > > > org.freesmartphone.Phone (highlevel), or org.freesmartphone.Device > > > (lowlevel) -> org.freesmartphone.Usage (highlevel). I think we should > > > still create a GPS level protocol that fits the dbus model better than > > > gypsy. > > > > Feel free to tell me that I'm totally clueless, as I may well be, but > > what is wrong with using gpsd for the GPS bit of that? > > > > gpsd apparently provides some sort of dbus -- I can imagine that there > > are things not exposed via dbus that could be, but isn't that a reason > > to request the extra stuff be added to gpsd's dbus rather than indulging > > in another round of wheel reinvention? > > It's not wheel reinvention, but abstracting all positioning services into > one position provider. GPS is one of the positioning services, but not the > only one.
Mickey is proposing both the abstract positioning interface and the lower level provider interfaces should be available. Phil is suggesting we stick with gpsd for the low level GPS interface unless anyone knows a good reason not to. > gpsd is (AFAIK) a GPS/NMEA multiplexer, in that it allows multiple _GPS_ > clients to get their positioning information, in NMEA format. A client > that relies on this will have to be rewritten if another positioning > provider is used, or if ublox is used instead of NMEA. That was true once, but gpsd has moved on. It can read from most binary GPS protocols now, including ublox. The gpsd protocol is changing to a JSON based one, and there is a dbus interface too, though it appears new and undocumented. http://gpsd.berlios.de/gpsd.html > An abstraction layer on top of that will make it independent of the > technologies or protocol used, and will also allow orchestration in the > case of multiple providers to increase accuracy for example. Additional > benefit is that the clients using this abstract layer automatically > support any underlying positioning tech. > > And, even with an overlying abstraction layer, you can still use the > lowlevel interfaces if needed. > > grtz, > Sander > > _______________________________________________ > smartphones-standards mailing list > smartphones-standards@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards > _______________________________________________ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards