[gpsd-dev] RFC - drop "tag" fields from the public interface

[Eric S. Raymond]

There's going to be a libgps version bump in the 3.12 release.  This
makes it a good time for a featurectomy I've been thinking
about.  I'm requesting comments.

The "tag" field in JSON reports is a historical relic from before the
design of the JSON protocol, back when there was fairly close
correspondence between one GPS sentence in and one GPSD report
sentence out.

Now that JSON reports correspond to the last GPS sentence in some
group composed to gather all their information, that correspondence is
gone.  In the NMEA case, for example, a TPV is composed from up to
four sentences and the tag only tells us which one happened to arrive
last.

I think this is useless.  I'm contemplating removing tag
fields from the data exposed by the JSON - might have done it
sooner, but it certainly wasn't worth forcing a library version
bump for this.

This featurectomy will drop out a bunch of dodgy code in binary drivers under
which there isn't a hard and fast notion of "tag" for sentences and
you have to make one up from the number of the sentence type.

Does anyone have - or can anyone even imagine - a use case for the
tag fields as they are now?  If so, speak up.  If all I hear is
crickets, I'll drop them.  Affirmative responses of the form
"I have no use for the tag field" would be useful, too.
--
                                                >>esr>>