The JSON driver

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> > I can't figure out what you're recommending here, and I want to because I
> > believe in taking you seriously even when I think you've just said something
> > actually *silly* for the first time in recorded history.  Cleaning up the
> > parsing code in the driver? Changing the way it's generated in gpsd?  What's
> > the axis of "better" here? 
> 
> I'm not sure.  Probably ease of understanding and/or maintaining.  (You can 
> change the gpsd end if that helps.)
> 
> I think it's simple to write/send stuff encoded in JSON.  I don't know how to 
> do the read/recv side.
> 
> Is there a good library/package to do the parsing?  Do we want to add another 
> library to the list of requirements?

There's one in the tree already, under libjsmn.  It only does tokenization.
I think it's barely adequate.  I wrote a much more powerful library for GPSD
that parses JSON data directly into C structure slots, and spun it out
as a project called microjson.  I say "library" but it's one fairly short
C file and a header, both very stable.  Including them in the tree
would be reasonable.

I hven't done this in part because I question whether the JSON driver is
a good idea on any level. I've thought about removing it.  The SHM driver
does as good a job with less overhead and none of the flakiness that is
now 50% of the bugs on our tracker.

> One of the things that's missing by just saying "JSON" and expecting all your 
> troubles to be over is a layer of type checking.  I hate discovering at run 
> time something that should have been detected by the tool chain.

But CSV ain't going to give you that either.  Nor is YAML, XML, or any
other metaprotocol.  If you want CORBA, you probably know where to find it. :-)

> For the case of a simple struct, I'd expect the sending side would be one line per field.  (with probably another line each for start and finish)  Can the recv side be as simple?  I'm expecting each line to be a subroutine call with a subr for each data type.  (int, float, text, bool...)
> 
> Is there a tool that turns a struct into the appropriate set of calls?

No. You might want to read json.c and libgps_json.c in the GPSD distributon.
You won't like it, I'm sure , but it will be enlightening.

> What are the rules for JSON?  Is the order of fields part of the specs?  Could I do the recv with a readline and a big sscanf?

The order of fields is not part of the spec, so that won't work.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>