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

[Florian Forster]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090411/4d7e6c98/attachment.bin