Re: [gpsd-dev] OBD data, suitable for GPSd inclusion?

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> So, speaking personally, if you submitted patches to gpsd that can
> be disabled at compile time they might be accepted if you can keep the
> changes fairly unintrusive to the core gpsd functions and goals.

Project lead agrees, Derek.

if you follow through on this you may pose us an interesting philosophical
challenge.  Consider this that I wrote about the architure for the anthology 
"The Architrecture of Open Source":

    Unix programmers schooled in the tradition of "do one thing well" may
    ask [...] why gpsd now handles non-GPS sensors like magnetic
    compasses and Marine AIS receivers, and why we contemplate
    possibilities like ADS-B aircraft tracking.

    These are fair questions. We can approach an answer by looking at the
    actual complexity cost of adding a new device type. For very good
    reasons, including relatively low data volumes and the high
    electrical-noise levels historically associated with serial wires to
    sensors, almost all reporting protocols for GPSs and other
    navigation-related sensors look broadly similar: small packets with a
    validation checksum of some sort. Such protocols are fiddly to handle
    but not really difficult to distinguish from each other and parse, and
    the incremental cost of adding a new one tends to be less than a KLOC
    each. Even the most complex of our supported protocols with their own
    report generators attached, such as Marine AIS, only cost on the order
    of 3 KLOC each. In aggregate, the drivers plus the packet-sniffer and
    their associated JSON report generators are about 18 KLOC total.

    Comparing this with 43 KLOC for the project as a whole, we see that
    most of the complexity cost of GPSD is actually in the framework code
    around the drivers—and (importantly) in the test tools and framework
    for verifying the daemon's correctness. Duplicating these would be a
    much larger project than writing any individual packet parser. So
    writing a GPSD-equivalent for a packet protocol that GPSD doesn't
    handle would be a great deal more work than adding another driver and
    test set to GPSD itself. Conversely, the most economical outcome (and
    the one with the lowest expected cumulative rate of defects) is for
    GPSD to grow packet drivers for many different sensor types.

    The "one thing" that GPSD has evolved to do well is handle any
    collection of sensors that ship distinguishable checksummed
    packets. What looks like mission creep is actually preventing many
    different and duplicative handler daemons from having to be
    written. Instead, application developers get one relatively simple API
    and the benefit of our hard-won expertise at design and testing across
    an increasing range of sensor types.

Full essay at <http://www.aosabook.org/en/gpsd.html>

I wrote that, and I stand by it, but nobody has implicitly asked us to step
quite so far away from navigational sensors before.

> The other option is also open to you.  Since gpsd is BSD licensed it
> should be easy for you to fork the code if that eventually seems best.

Given the way Derek has described the problem, I'm far from sure he could reuse
enough of our code to make that worthwhile.  The packet-sniffer wouldn't
help him. The dispatcher layer might, but...ugh.  Just cutting out the parts
he can't use would be a big, messy job.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature