[collectd] I guess we need a config file

[David Bacher]

Hello,

 In general, I support the addition of a config file. For my
application (monitoring a number of embedded systems), distributing a
config file in my collectd_client package just makes sense. In
addition, it allows certain hardcoded elements to be configurable
without adding tons of command line options (like the multicast
address / port).

 However, from the point of view that now even the collectd client
will have external dependencies, I am somewhat wary. As niki pointed
out, glib is not exactly lightweight and in turn depends on other
libraries. (Although, to be honest, expat, gettext and iconv are
fairly common libraries and making sure those dependencies are ported
would not cause me a great many problems.) But the original
lightweight nature of collectd was exactly what drew me to it in the
first place.

 Similarly, I'm not sure I really understand the benefits of adding
threads. Are there places where collectd modules are getting bogged
down? Perhaps I should review the mailing list archives for
performance issues. I certainly agree with niki that thread support
should be optional.

 In any case, this is all just my opinion and I'm still appreciative
of the project and your willingness to discuss potential improvements.

 Cheers,
 -dave


On 12/9/05, Florian Forster <octo at verplant.org> wrote:
>  Hello everyone,
>
> there are two things on my mind:
> 1) Use threads to parallelize the modules (as described before).
> 2) I'm in the process of writing a module for MySQL. For that to work I
>    need (configurable) username, hostname, port and _password_. Since I
>    won't pass the password on the command line I'd say it's time we got
>    ourselves a config file.
>
> For both issues there's a solution. It's easy and, in my opinion,
> elegant: Pull in `glib'. It provides data-structures which we could use,
> simplifies shared libraries, provides thread-abstraction (threadpools,
> also) and, last but not least, has a config parser with a simple and
> powerful syntax.
>
> Apparently glib's interface hasn't changed much between  1.x and 2.x, so
> I hope to be version-independend. But since I don't have any experience
> with glib I can't promise that..
>
> Before I start doing big changes, does anyone have anything to note?
>
> In the meantime, I'll pack another release to get the `users' module
> published ;)
>
> Regards,
> -octo
> --
> Florian octo Forster
> Hacker in training
> GnuPG: 0x91523C3D
> http://verplant.org/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG  v1.4.1 (GNU/Linux)
>
> iD8DBQFDmaDijvke9ZFSPD0RAv/8AJ0ankGMUwLslICoV9GU04FgDkIWMACeNTRf
> rAYkDax8jgFZiXPXpcxZ0eY=
> =kYoG
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
>  Collectd mailing list
> Collectd at verplant.org
> http://mailman.verplant.org/listinfo/collectd
>
>
>



--
David Bacher  _..  ._  ..._  .
drbacher at alum.mit.edu