[rrd-developers] [RRDCacheD] Developing RRDCacheD as separate project (was: Authentication)
kbrint at rufus.net
Fri Apr 10 15:14:19 CEST 2009
On Fri, Apr 10, 2009 at 02:01:21PM +0200, Florian Forster wrote:
> > I love the rrdcached functionality and all the work you did on it and
> > I would not want to miss it.
> > But it also makes me sad to see you angry or unhappy. So if you feel
> > that it is better for you to run your own show, I am perfectly ok with
> > you doing a fork of the cache daemon and hooking it up to librrd. This
> > will give you the freedom to develop it in any direction you feel is
> > sensible.
> Yes, I think separating the development would make sense and ultimately
> the open-source community will benefit from it. The bonding between the
> daemon and RRDtool would be lessened, but that isn't necessarily a bad
> thing in my opinion. RRDtool wouldn't have yet another binary interface
> to worry about and new releases of either project could be made whenever
> appropriate and independently from one another.
Personally, I think it's better off with the main RRDTool code:
(1) The daemon may require access to internal structures/functions at some
time. Of necessity, an independent project would then drive changes
to the externally visible ABI; thus, will both be coupled to the
librrd.so version, and will lag behind the RRD release cycle.
(2) The client must remain in the main RRD distribution; if not, there
will be no significant adoption. Therefore, the on-the-wire protocol
will always couple the client and the server.
(3) An independent rrdcached will likely increase the number of
client/server permutations, making troubleshooting harder for both
sets of developers.
(4) The same set of developers are likely to working on both code bases.
There will be significant overlap. To put it another way, it's
extremely unlikely that someone would be interested in the rrdcached
code and NOT in the main RRD distribution.
(5) rrdcached is unlikely to serve any other purpose than to accelerate
RRD performance. It is a domain-specific solution.
(6) An independent rrdcached is unlikely to have as many developers
scrutinizing the code, esp. new submissions.
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. 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.
> "Forking" the daemon, i. e. leaving the daemon in RRDtool and developing
> a second one, is out of question for me: This would create a diversity
> nobody would benefit from.
> It'd be nice to hear some more opinions on the matter, especially which
> development model Kevin would prefer and whether or not he'd volunteer
> to maintain a separate project?
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. Too much has already been gained.
Let's work through our differences and write some good code.
kevin brintnall =~ /kbrint at rufus.net/
More information about the rrd-developers