From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B2B7AA00C4; Wed, 27 Jul 2022 11:49:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6214440141; Wed, 27 Jul 2022 11:49:26 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 14E30400D7 for ; Wed, 27 Jul 2022 11:49:25 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v2 00/13] telemetry JSON escaping and other enhancements Date: Wed, 27 Jul 2022 11:49:23 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D871F3@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v2 00/13] telemetry JSON escaping and other enhancements Thread-Index: AdihmQ/bK81EIvqDTVOBIUuTfjxaNwAAqeyw References: <20220623164245.561371-1-bruce.richardson@intel.com> <20220725163543.875775-1-bruce.richardson@intel.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "fengchengwen" Cc: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Wednesday, 27 July 2022 11.13 >=20 > 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 =3D RTE_TEL_STRING; > > d->data_len =3D strlcpy(d->data.str, str, sizeof(d->data.str)); > > // e.g. do escape here! > > if (d->data_len >=3D RTE_TEL_MAX_SINGLE_STRING_LEN) { > > d->data_len =3D 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. The telemetry library currently only implements JSON as the output = format. I understand why this gives the impression that it depends on = JSON. But it does not. When the DPDK telemetry library was initially discussed, JSON was the = only target. Before that settled in too deeply, I argued for using = generic data types internally, so it could support other formats (e.g. = SNMP), which resulted in the current layering of the telemetry library - = a both elegant and practical solution. > > > 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. >=20 > 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. >=20 > 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. >=20 > /Bruce JSON encoding belongs in the JSON output layer. Don't make assumptions about other output formats! The char '\' might = not be legal in all output formats. And I certainly don't want any = newlines escaped in SNMP text objects.