[rrd-developers] [RRDCacheD] Developing RRDCacheD as separate project (was: Authentication)

[Yann JOUANIN]

Did a reply with getting the list as destination ...




I just would like to add a point in favour of "keeping RRDCacheD in RRDTool".

As a "end user", in a production environment of a datacenter, I do the decision of which tool has to be used, but I am not the one who administer the servers.

Nowadays, I required an exception to the rule in order to get the right to compile RRDCacheD on this machines. But in a normal running time, administrators refuse to install softwares other than Debian packaged.

Here is my point of view about RRDCacheD when it will be considered as "stable" :

Knowing how most of package repositories work, I think splitting RRDCached from RRDTool could have as effect to have in the most common distribution :

1) RRDTool available but not RRDCacheD
2) RRDTool and RRDCacheD available but not at the same version.



Yann Jouanin
http://www.yannj.fr

-----Message d'origine-----
De : rrd-developers-bounces at lists.oetiker.ch [mailto:rrd-developers-bounces at lists.oetiker.ch] De la part de Florian Forster
Envoyé : samedi 11 avril 2009 10:19
À : kevin brintnall
Cc : rrd-developers at lists.oetiker.ch
Objet : Re: [rrd-developers] [RRDCacheD] Developing RRDCacheD as separate project (was: Authentication)

Hi Kevin,

thanks for your reply, it was very important for me to hear your point, too.

On Fri, Apr 10, 2009 at 08:14:19AM -0500, kevin brintnall wrote:
> (1) The daemon may require access to internal structures/functions at some
>     time.

Please, PLEASE, don't ever do that! Having a well defined API and a binary interface which exposes only those symbols is rule no. 1 for each library. And from the point of view of librrd{,_th}, the daemon is yet another external program.

> (2) The client must remain in the main RRD distribution; if not, there
>     will be no significant adoption.

I think it'd be cleaner if the daemon came with a client library, e. g.
librrdcacheclient, which provides high-level access to the protocol. The `rrdc_*' functions are basically what this library would provide.

Making this library optional when building RRDtool is not hard, so people who don't need the daemon don't have to worry about it.

> (3) An independent rrdcached will likely increase the number of
>     client/server permutations, making troubleshooting harder for both
>     sets of developers.

You should see “the daemon” as yet another library (from the point of view of RRDtool). Once separated, the relationship between RRDtool and the RRDCacheD would be similar to RRDtool and libdbi. As far as I've seen no serious trouble has come from that direction yet..

An increase in releases would be a very good thing. For one, we'd be able to release the daemon right away instead of forcing people to use it out of the SVN repository (and with a development version of RRDtool).

> (4) The same set of developers are likely to working on both code bases.

> (5) rrdcached is unlikely to serve any other purpose than to accelerate
>     RRD performance.  It is a domain-specific solution.

Both true, but in my opinion neither really arguments for nor against a separated development model.

> (6) An independent rrdcached is unlikely to have as many developers
>     scrutinizing the code, esp. new submissions.

This might be true, but it's hard to tell. There haven't been many contributions as-is either. I think that RRDCacheD is mostly used in a professional environment where you have to explain to your boss'es boss why you're running “development == experimental” code. I expect an increase in contributions once the code has a version number on it. With the above argument, that a separated development model would allow for more releases, it may well be the other way around, i. e. a separate project getting more contributions.

> Point (6) is, I believe, how this discussion started.  I agree that an 
> independent rrdcached would afford its developers more latitude, if 
> only because there will be fewer of them.

I think the point is not that there were less people involved, but that it'd be a smaller project where backwards compatibility is much easier maintained and release cycles can be increased dramatically.

> However, having a variety of opinions from committed, competent 
> developers will almost always lead to more robust, extensible, well 
> designed code...  and that's why *I* code.

And that's why we have this discussion :)

> If there is overwhelming consensus in the community, then yes I am 
> willing to maintain a separate project. However, I don't think that's 
> the right decision.

Then, by definition, it's not a “consensus” but a “compromise”. I'd much rather convince you and everybody else ;)

Regards,
-octo
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/