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

[kevin brintnall]

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.

Agreed.

> 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/