Re: some observations on the design intent of gpsd

[Don Rolph]

The key question is why strip out the rest of the functionality from the interface.

And I simply note that we have spent a fair amount of time on the present interface which based on my testing so far seems to be driven by the relative complexity of the interface.

We have a working 3.17 piece of software.

And I have shown that the same software fails against the 3.23.2~dev server.  And so far no one seems to be able to explain why or provide a viable path forward.

A single location interface which is invariant would seem to ease this problem.

I made a comment because the present migration seems to be having issues and this triggers my thought on how could this be made simpler.

But as I noted, these are my opinions and your mileage can and will vary..

On Wed, Jan 5, 2022 at 3:19 PM Gary E. Miller <gem@rellim.com> wrote:

Yo Don!

Can you please use a standard quote style?  If you can't follow
email standards, why would you expect to follow GNSS standards?

On Wed, 5 Jan 2022 14:51:15 -0500
Don Rolph <don.rolph@gmail.com> wrote:

> Let me clarify on some of your points:

I thought it was clear the first time.

>
> Your material:
>
> > Many users, however, are looking for an abstraction layer over
> > location. 
>
> Care to clarify what is "over" location?  gpsd stops at giving you
> lat/lon/alt.  If you want your street address, then pass that up to
> a map program.  If you want your statistics, pass that to gnuplot,
> etc.
>
> My response:
>
> actually based on some ontology work I have done, lat/log/alt with
> possible speed and header are the key information elements.

Yes, of course.  Which is what gpsd gives, many ways.

> However, creating an interface which provides this capability AND
> supports the additional gps data structures seems to add complexity
> to the service.

Which is why gpsd provides many simple ways to get the lat/lon/alt.
Why not use one of them?  The DBus service from gpsd sounds about right.

OTOH, I don't see how a 10 line client for JSON is a big burden.

> At the locatio abstraction layer, strip out all but
> locations and associated data

Why strip it out?  Just ignore it.  If complexity is a problem, then
use the DBus interface.

If a 10 line client is too hard, give up now.

> and have a stable interface across
> changes in the satellite data,

gpsd has that.  The lat/lon/alt  int the TPV part has been pretty
stable for what?  15 years?  Compare that to openssl, ffmpeg, http, etc.

> > While gpsd provides a location abstraction layer with the TPV
> > message, the additional complexity of providing an abstraction layer
> > over most gps receivers complicates the use of gpsd as an
> > abstraction layer over location. 
>
> Uh, lost me.  That seems circular.  I look at it this way: you
> start gpsd, you get lat/lon/alt out.  What more, or less, do you
> want?"
>
> I reply:
>
> an interface whose only message is position.

Sounds like the DBus interface.  Or the JSON interface when you just ignore
the stuff you don't want.  Ignroing data costs nothing.

> That way when satellite
> data changes, it does not impact this interface.

Uh, lost me again.  What changed?

> Creating a call
> which can be restricted to TPV messages but must also maintain
> support for other changing messages, appears to be adding complexity
> to the user calls.

Good, then we will not do that.  Why bring up ideas you do not like?

> "> You can actually see the Dire Wolf author's design includes this
> > wrapper approach, although it is nascent at the  moment. 
>
> Please, don't bring up the broken Dire Wolf code as an example of
> anything but laziness.."
>
> I reply:

Once again, don't care.

Yes, please do not do so.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

--

73,

AB1PH

Don Rolph