Re: [gpsd-dev] Adding new fields to JSON reports

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > Maybe this needed to be done, but you left the job very incomplete.
> > As a result, gpsmon is almost certain to have flaky failures.
> 
> WIP.  You just beat me to it, 5 mins not a long time for me to upload
> the next patch...

Given the amount of PPS testing we're doing right now I decided not
breaking gpsmon was important enough that I should go ahead and fix
that part.  

You get to write the unit test in test_json.c, though. And you're fully
on the hook for the next time, now that you know the procedure.
 
> > 4. Update the JSON parse templates in libgps_json.c.  If you don't do
> > this, clients (including gpsmon) will throw an error when they trip
> > over the new field.
> 
> That seems less than ideal.  Clients should be able to handle upwardly
> compatible changes with at most a warning.  If you can force this to 
> happen with precision I'll fix it.

It's a little complicated.

The parse error isn't fatal, and all data extracted up to the poiint
of the unrecognized attribute is valid. So you can often get the effect of
upward compatible extension by declaring the new attribute last in the
parse template structure and ignoring a JSON_ERR_BADATTR status.  The
new precision attribute is in fact declared last.

The problem is that if you do this you will fail to detect genuine errors,
like a mispelled attribute name.

I didn't want to let this particular one ride because gpsmon has a
history of core-dumping when I tried to use json_error_string() to
report parse errors.  Better to solve that problem when we're not up
to our eyebrows in PPS issues.

> > 5. The hard part: the data wants to go somewhere on the client side,
> > but doing this may involve a compatibility break in the user-visible
> > core structures.  You need to make a call on whether to extend them
> > or accept that the new data will be invisible untol the next
> > structure upgrade and if so document that as an item in TODO.
> 
> Which also make me questions the core structures.  Maybe better to
> convert to a hash style so field can be added with less downside?

Indeed, that plan works very well = in Python or any other language
that has hashes as a first-class datatype.  In C there's really no help
for this, the native type ontology is too weak.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>