Jakub Narebski <jnareb@gmail.com>:
quoted text
> [JSON] is a bit chatty, but is to some extent self documenting.

Yes. But to my mind, the big win of JSON is that you can extend it without
breaking parsers looking for older versions - they just skip the new
fields and all is happy.

Jakub, you seem to know this, but other listmermbers may not: I've
recently re-engineered GPSD, a service daemon for watching geolocation
sensors, to report JSON objects up the socket to client apps.  The
benefits in clarity and extensibility of the protocol have been
*huge*.  Like, today I'm adding a reporting type for digital
compass/gyroscope sensors.

quoted text
> The question is whether it should output well formed array of objects,
> or just list of objects not wrapped in array...

Yes, I know this dance.  Answer: one big JSON object, tagged by the
name of the output generator, and also *containing a version-stamp
field*.  Array of file status objects is another top-level member.

The point is: later, if we want to enrich the reporting format, we add
whatever fields we want and bump the version stamp.  Self-describing
goodness.  Python, Perl, JavaScript, and Emacs LISP clients win
especially big.  Slurping this into a native data structure is one
function call.

The more I think about this, the better I like it.
 
quoted text
> What I am worrying about is correct handling of escaping, quoting,
> and non-ASCII characters in strings (the JSON-quoting and JSON-escapes
> are different than C escape codes, IIRC).  JSON rules are simple,
> but are different than C.

Yes. Perhaps there's some scope for reuse here after all.  GPSD has
well-tested code for uttering the JSON quote/escape conventions. 
The git project is welcome to it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html