Duy Nguyen <pclouds@xxxxxxxxx> writes: > These trace messages are made for human consumption. Granted > occasionally we need some processing but I find one liners mostly > suffice. Now we turn these into something made for machines, turning > people to second citizens. I've read these messages reformatted for > human, it's usually too verbose even if it's reformatted. I actually actively hate the aspect of the slog thing that exposes the fact that it wants to take and show JSON too much in its API, but if you look at these "jw_object_*()" thing as _only_ filling parameters to be emitted, there is no reason to think we cannot enhance/extend slog_emit_*() thing to take a format string (perhaps inside the jw structure) so that the formatter does not have to generate JSON at all. Envisioning that kind of future, json_writer is a misnomer that too narrowly defines what it is---it is merely a generic data container that the codepath being traced can use to communicate what needs to be logged to the outside world. slog_emit* can (and when enhanced, should) be capable of paying attention to an external input (e.g. environment variable) to switch the output format, and JSON could be just one of the choices. > It's not just sampling points. There's things like index id being > shown in the message for example. I prefer to keep free style format > to help me read. There's also things like indentation I do here to > help me read. Yup, I do not think that contradicts with the approach to have a single unified "data collection" API; you should also be able to specify how that collection of data is to be presented in the trace messages meant for humans, which would be discarded when emitting json but would be used when showing human-readble trace, no?
