Jakub Narebski <jnareb@xxxxxxxxx>: > [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. > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html