On Thursday 15 October 2009 11:54:41 Al Johnson wrote: > 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.
I know, I'm not suggesting otherwise :) I was merely supporting Mickey's point of view of having both high and low level interfaces. > > 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 Ok it seems gpsd is starting to provide the highlevel abstract interface. Good. I still hope though that the distinction and separation between high and lowlevel will be maintained. grtz, Sander _______________________________________________ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
