Hi, On Thu, Mar 18, 2010 at 10:35:09PM -0700, Chris Buben wrote: > On Wed, Mar 17, 2010 at 10:36 AM, Bob Cotton <[email protected]> wrote: > > For systems that are "far away" from collectd without access to the > > types database, it would be nice to have this info. > > Agreed, looking for the same thing too.
yeah, good point.
> > May I suggest a format for the JSON to incorporate this data. Again,
> > using load as an example:
> > [
> > {"values":{"shortterm:GUAGE":0.0561523, "midterm:GUAGE":0.188477,
> > "longterm:GUAGE":0.276855},
I'm not a big fan: After parsing the JSON format, you need to parse the
strings that are the keys of the hash to separate the name and the type.
Second, it breaks backwards compatibility.
> Why change the structure of "values"? Since the count of values, DS
> names, and DS types will always be the same, why not just introduce
> two new arrays, "dsnames" and "dstypes"? Then the change would be
> backwards compatible, and a configuration switch could be added to
> enable this additional "DS metadata".
That's basically what I was going to propse (but then read Chris' email
;). I think we can even get away without the config option. If someone
wants to remove that data again for some reason (performance, most
likely) we can always introduce it later.
Regards,
-octo
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
signature.asc
Description: Digital signature
_______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
