Re: [gpsd-users] GPSD 3.5 has shipped

[Eric S. Raymond]

Ed W <address@hidden>:
> >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.
> 
> Can you clarify exactly why?

I thought I already did.  Spec languages are good if - for example - you
know that your instances of GSA will always have the right number of fields
and be syntactically well formed.  As you try to deal with malformed inputs
the complexity of the spec (and its interpreter) tends to explode.

> Just to be clear - I don't want to rewrite anything, nor throw away
> 8 years of anything?

Um, you mean you're not advocating replacing the NMEA driver with something
generated from a declarative spec a la OpenCPN?

> I'm not sure why this is inconsistent with a simple parser for where
> it works?  If some of the code needs spaghetti then so be it - just
> to be clear I'm not recommending to rewrite any of the existing
> GPSD, simply adding existing NMEA parsers on top of what we have.
> If the bulk of those parsers can be done easily written then so much
> the better

Oh, I see. *Partial* replacement.  Opens a can of worms; one is managing
the boundary between generated and ad-hoc code.  Not ruling it out
entirely, but I can guarantee it will be messier than you're expecting.

> Do you really anticipate that if we exclude GPS and AIS, that the
> rest of the relatively simple NMEA sentences are going to have the
> same level of hairballs?  I don't mean that as a challenge - genuine
> question?

I'll just say *nothing* in my experience of NMEA makes me optimistic
on this score.

>                                                         Can we not
> consider whether there is some low hanging fruit here which can be
> easily grabbed?

Consider it?  I've already done it.  Go look at how the JSON deserializer
code for AIS is generated.

> >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.
> 
> You raise two points here:
> 
> 1) Given that low cost, certified interfacing products appear to
> exist, are you saying that you refuse to use them at all, or that
> you want to support both them and direct integration?

Sorry, I don't understand the question.  I have a request for NMEA2000
support, a code contributor, and an implementation strategy.  I don't
see how the existence of other products is relevant.

> 2) NMEA2K isn't quite like NMEA 0183.  You now have two way talkers
> and a much expanded spec on cabling, termination and devices.  It's
> not quite standard CAN, even though the signalling is CAN.  I don't
> see any issue with hackers plugging in, but I think it's a dead end
> from the point of view of any kind of integrator wanting to sell it
> as "NMEA2K".

That's not my problem.  The best we can do is supply capabilities to
the limit of our technical capability to implement them.  We can do nothing
about NMEA's policy decisions, and the system integrators can make their
own decisions about seeking certification. None of that has anything
to do with us.

> You have presumably poked around a bit with the CAN stuff already?

Yes.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>