Re: [PATCH v2 00/13] telemetry JSON escaping and other enhancements

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jul 27, 2022 at 09:51:04AM +0800, fengchengwen wrote:
> Hi Bruce,
> 
> I think escape the string at begin (following function) seem more simple:
> 	rte_tel_data_string
> 	rte_tel_data_add_array_string
> 	rte_tel_data_add_dict_string
> 
> int
> rte_tel_data_string(struct rte_tel_data *d, const char *str)
> {
> 	d->type = RTE_TEL_STRING;
> 	d->data_len = strlcpy(d->data.str, str, sizeof(d->data.str));
> 		// e.g. do escape here!
> 	if (d->data_len >= RTE_TEL_MAX_SINGLE_STRING_LEN) {
> 		d->data_len = RTE_TEL_MAX_SINGLE_STRING_LEN - 1;
> 		return E2BIG; /* not necessarily and error, just truncation */
> 	}
> 	return 0;
> }
> 
> Advantages:
> 1. simpler implementation
> 2. application are directly visible the result (by judge API retval) without waiting for JSON encapsulation.
> 
> Disadvantages:
> 1. not friend for new output format, but currently telemetry deep depend on json, so I think it's OK for it.
>
I'm quite happy to implement things in a simpler way, however, in the past
there was a great concern to keep things flexible enough for future changes
to add other output formats. By that logic, keeping the escaping in the
json layer is the correct design choice.

However, adding escaping on addition to the return data structure may not
be that much of an inconvience to other output formats too, so perhaps it's
acceptable.

Again, looking for more input and consensus from the community. I am happy
to go with either approach for escaping - putting it in the data return
layer or the json one.

/Bruce