On Thu, 2012-04-05 at 15:44 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> PMAPI says in a few places that text strings (metric names?
> PM_TYPE_STRING metrics?) are limited to ASCII. Do you foresee the
> need to generalize that to pass Unicode/UTF-8 strings, or general
> charset/encodings? ...
Internally PM_TYPE_STRING values are treated as a container with a
length prefix, supporting non-ASCII strings would involve:
- adding PM_TYPE_UNICODE and/or PM_TYPE_UTF_8
- piggy-backing on the PM_TYPE_STRING cases in most places, except where
we compute the length, strlen() would need to be replaced by the
Unicode/UTF-8 equivalents.
Not a big deal, just that no one has asked for it before ... remember,
PCP was conceived in an era in which ASCII encoding for characters has
only "recently" won the 8-bit encoding battle between BSD, EBCDIC and
ASCII ... 8^)>
> ...
> Similarly, any thought as to mime-typing the
> binary PM_TYPE_AGGREGATE metrics?
OK this is might get messier. PM_TYPE_AGGREGATE is a blob, i.e. a
length and an array of arbitrary bytes. If a PMDA and a PMAPI client
agree on how to encode mime type and value info within the array of
bytes, then it would just work (tm), but if PCP needs to be taught about
mime-types, that's a whole can of worms I'd rather not open.
|