[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Using multiple location sources to improve accuracy and r

From: Olivier Cornu
Subject: Re: [gpsd-dev] Using multiple location sources to improve accuracy and reliability
Date: Sat, 14 Jul 2012 14:20:46 +0200

On Tue, Jul 10, 2012 at 9:19 PM, Gary E. Miller <address@hidden> wrote:

On Tue, 10 Jul 2012 10:49:31 +0200
"address@hidden" <address@hidden> wrote:
>       For me the point is, that there is already so much code in
> gpsd that address the needs of only very few people, and this options
> need difficult configuration, and it may be implemented in so many
> different ways.


There is also much code violating the separation principle: what do wind direction or sea temperature have to do with GPS devices and gpsd, for example? I guess such things get included only because they share the same NMEA protocol than GPS devices (and sometimes the same physical line). If we were serious about separation, these should go into their own nmead, not gpsd, right?
How is best-guess fix code any different? It also shares a protocol (gpsd) and a logical line (GPS→client); And it happens to have something to do with GPS devices and your actual location.

How come water temperature or AIS rightfully belong to gpsd and a best-guess fix does not?
I'm not asking for the favor of including alien code because other alien code got included too. Just saying: get your story straight.
If policy is what makes the difference, in other words if gpsd actually is a sensor multiplexer, then it should change its name to reflect that choice: what about sensord? No matter how you put it, it is quite reasonable to expect a gpsd software to actually provide serious (i.e. best effort) GPS-based location data.  :-)

Now, if gpsd actually is sensord, i do agree a locationd daemon can make sense. Yet it would still be a virtual device getting all its input from sensord and broadcasting its messages to clients through sensord as well.
So i'd keep arguing it's architecturally sound and computationally more efficient to implement such necessary virtual devices (no matter their implementation is policy-based or only "mechanical" or anything else) into sensord rather than in distinct daemons. In fact, i'd also argue that segregating among virtual devices based on what they do with the available data is probably an architectural mistake: as long as they comply with the virtual device interface, it's none of our multiplexer business.

Olivier Cornu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]