Re: RRD C API's for RRDCACHED
Florian Forster <[email protected]>
| Newsgroups | gmane.comp.db.rrdtool.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Nov 13, 2010 at 10:58:33AM +0000, Alex Bennee wrote: > On 12 November 2010 19:39, Florian Forster <[email protected]> wrote: > > the RRDCacheD interface uses a set of separate functions, prefixed > > by "rrdc_" (mnemonic: RRD Client). The functions are similar in > > syntax to the thread-safe interface using the "_r" suffix. > > Is this the preferred method of calling? I've just been using > rrd_update() with the RRDCACHED_ADDRESS environment variable set and > it's been working fine. Did I miss something? In *my* opinion it is the superior way of using the caching daemon; using the environment varialbe is just a dirty hack to use the functionality from unaltered applications. Using the "client functions" has the great benefit that you *know* there's a caching daemon addressed when reading the source code. If you use the hack, you might wonder why "update" fails although "create" didn't return an error, for example. Also, for cache specific functions you have to use the interface anyway, for example to send a "flush". Using a combination of both methods is even more confusing. Please keep in mind that this is merely my $.02. Regards, --octo -- Florian octo Forster Hacker in training GnuPG: 0x0C705A15 http://octo.it/ _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
signature.asc
(application/pgp-signature, 835 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJM3taGAAoJEMPSHpbi2Mmg9RgP/2SZu4gCutf2XYtPP9R6Lngd ArwMuPqBf0n3slo3Bw4XGElSvOridxMZDTEZld8s2SPh6iGrs7jC7cUp8VdQekDX m35210QnuHqb1zaU17LwabhwyuwAlJn8T8lN8c2cViLWhGOUZt02CKaf9jcJerK3 0RhgzoDvFgbbxLU+YJ0iiq7+xZnkgQS6gBBJHwniR4VFFxsWeMXCD9mPLjczBgqa zSC78y3lwbm0wRpBrZpt5WUapEP2cX51qpUdSrU/nV6TZaUoPbFfmZ7FTKDnaXVp grfkSvZ9BBNONAwz01vpw4jJaYR+Qq3xl3bbVeL8L2Nsan+E2SpWX40Cu4LIbt2F YzELBe14vbadMUjJfOyuETdkeuf+iOI81qY+JnClOZpCHGmfeIaEsouWKFuIRbLE ZfVBLrhGiTXjNWNh2kadFzXm5q96VeMvIUkWfyMwXmrvTjQPKHdoOwwCpE5GbJ1o MppMOgEtuzhde7ZqK+TjpsotPmNpajskfAPnJhFF/+wzia34esgtqax+oZmahCYr hui7fVQjaP/wyPY+wHpqvR/BUAJk5qQRcV89Xzy/yYZDfTidJCxFl7FC1aJChHhD Mjz0qd3iPexk4HeK7XM2tWaLd3zktH3kP2e9b/P8knvj/eqZ9oAQlHG0G81DwU5x tWawDWb6Jug5s755a9x+ =zKeY -----END PGP SIGNATURE-----