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 =~ /kbr...@rufus.net/ _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers