Luiz Capitulino wrote: > On Fri, 07 May 2010 16:21:13 +0200 > Jan Kiszka <jan.kis...@siemens.com> wrote: > >> Luiz Capitulino wrote: >>> On Fri, 07 May 2010 13:45:03 +0200 >>> Jan Kiszka <jan.kis...@siemens.com> wrote: >>> >>>> Hi Luiz, >>>> >>>> what is the recommended way of pushing larger buffers (up to 64K so far) >>>> into a qdict? QLIST of QINT (one per byte) looks a bit heavy. I thought >>>> about hex-encoding the content first (series of "%02X"), then >>>> registering it as QSTRING. Or should we introduce a new type, QBUFFER? >>> I don't think that hex-encoding the contents is so bad if your use case is >>> very specific and isolated. >> The focus will be first on visualizing the buffer (user_print), but who >> knows what happens once the services is also exposed via QMP. >> >>> On the other hand, I do prefer a QBuffer type, specially because we can >>> have buffer operations. >> The q<type>.c files look sufficiently simply, guess I will add a buffer >> type. Still, hex-encoding is probably the best representation for QMP. > > Yes, either as a string or (as suggested by Markus) an array of numbers, > if you wish to expose this via QMP you (or any of us) will have to update > the parser to support it.
>From a quick glance at the JSON spec, there is no room for a new type. I think we have to overload an existing one and convert that into a QBuffer (typically, we know the actual semantic). Hex string encoding is most compact, so I went this road. But I'm open to change it into a true type if JSON actually allows it (or we are fine with breaking it). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
