Nathan Scott wrote:
Perhaps we could consider the above two things together - eg. if there's a
mmv.conf entry with a cluster#, use that with mmv. prefixed names, else we
use auto-numbering clusters and no mmv. prefix for other MMV files found
in /var/tmp/mmv ...? That'd still give people who want fixed PMIDs with
known clusters everything they need, and also give the flexibility other
people want.
As someone writing a library to dump stuff into this API from Javaland
(more details on that to follow shortly), this would be absolutely
brilliant. I like this a lot, +1 from me.
In terms of the string question which you raised earlier, I think that
what I was thinking matches what Max said -- basically add strings to
the end of the file and for string values, treat the value atom as an
integer offset, add that to the base address of the file, and then just
treat it as a char*.
For our purposes, I'm happy to make this part of the file a fixed size
(i.e. 256 bytes per string, which is what our existing MMV-like agent
has as an upper limit now).
So file format would become something along the lines of
Byte Content
0 Header
32 TOC 1 (type = metrics)
48 TOC 2 (type = instances)
64 TOC 3 (type = values)
80 TOC 4 (type = strings; no change to TOC content required I think)
96 ... metrics instances + values follow as per normal ...
x String 1
x+256 String 2
x+512 String 3
... and so on.
Does this make sense? Seems relatively easy and low-impact, I think.
Another option would be to have 2 types, STRING and SHORT_STRING, with
values known to be short (<=15 bytes) shoved in the 16 bytes allowed for
the pmAtom + DISCRETE/INTEGRAL space. Not sure if this is worth it.
Cheers,
Paul
|