Re: [gpsd-users] GPSD 3.5 has shipped

[Eric S. Raymond]

Ed W <address@hidden>:
> Please give some thought as to whether you could incorporate this?

Um.  Sorry, no. Theoretically elegant, but not practical for us.
The problem with doing that is that we'd basically have to throw away
eight years of hard-won knowledge about NMEA quirks of specific devices. 

Code generation from declarative specs is a beautiful technique - in fact,
GPSD uses it heavily, look at how jsongen.py works or the structures used
to drive the client-side JSON parser.  But in order for it to work, the 
domain you're generating code for needs to have regularity properties that
NMEA does not.

I do as much declarative specification as I can anyway, but in NMEA
having a table-driven dispatcher for individual sentence parsers is as
far as it can be pushed. 

For an example of the ways declarative specification can leave you *really*
screwed, consider these comments:

    /*
     * One chipset called the i.Trek M3 issues GPGSA lines that look like
     * this: "$GPGSA,A,1,,,,*32" when it has no fix.  This is broken
     * in at least two ways: it's got the wrong number of fields, and
     * it claims to be a valid sentence (A flag) when it isn't.
     * Alarmingly, it's possible this error may be generic to SiRFstarIII.
     */

    /*
     * Incrementing this unconditionally falls afoul of chipsets like
     * the Motorola Oncore GT+ that emit empty fields at the end of the
     * last sentence in a GPGSV set if the number of satellites is not
     * a multiple of 4.
     */

    /*
     * This sanity check catches an odd behavior of SiRFstarII receivers.
     * When they can't see any satellites at all (like, inside a
     * building) they sometimes cough up a hairball in the form of a
     * GSV packet with all the azimuth entries 0 (but nonzero
     * elevations).  This behavior was observed under SiRF firmware
     * revision 231.000.000_A2.
     */

By the time you've finished adding furbelows to your spec language to
handle cases like these, the spec will be as complex as equivalent
naive C code, and the interpreter/compiler for the spec language will
be a hairball, and you've got a two-layer maintainance nightmare worse
than if you'd just written the naive C.

I love the kind of techniques OpenCPN is using, but I know their
limitations, too.  What they're doing is trading away robustness in the
face of slightly broken devices.  And now you know why driver_nmea0183.c
looks the way it does.

> Depends on your long term goal, but this will be *EXTREMELY* hard to
> get NMEA2K certification this way.

My answer is: We'll make the code work.  What end-users and system
integrators do with it, and how they seek certification for their
binary images, is not our problem to solve.

If NMEA ever gets around to certifying implementations with a test
suite, we'll do what's required to pass that.  Until then, fsck their
bureaucratic noise.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>