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

[Thorsten von Eicken]

Well, if you open the discussion... I'd love to see the following:
  - RRDTool sans rrdgraph at the bottom layer for managing the data storage
  - An HTTP/REST style service that provides remote access to the data 
store using semantics that are relatively independent of the rrd details 
(at least for store/fetch requests, create can have a pile of specific 
args, for example)
  - An RRD graph library that has a pluggable back-end to fetch the data 
into which one can easily plug various storage systems, such as local 
RRD store, remote RRD store, or a different store altogether.

I believe the current RRDTool is not that far from the above 
architecture, but it's not there. Having an HTTP based service on top of 
the data layer would allow for a lot of flexibility. Like it or not, 
HTTP has become the standard plumbing, at least in my world. Think of 
passing the requests through a load balancer to spread the storage 
across multiple store servers. Or using HTTPS for security. I believe in 
the end the real bottleneck will remain at the disk level and the HTTP 
overhead can be accommodated.

Having the graphing be more decoupled from the storage is something that 
has been requested many times over, I believe.

Cheers,
Thorsten

Florian Forster wrote:
> Hi Tobi, Thorsten, Kevin, and list,
> 
> sorry I took my time to answer – I wanted to sleep on this first and
> don't make any premature decisions.
> 
> On Thu, Apr 09, 2009 at 04:31:02PM +0200, Tobias Oetiker 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.
> 
> I'd like to act upon a consensus here, though. “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?
> 
> On Thu, Apr 09, 2009 at 07:52:21AM -0700, Thorsten von Eicken wrote:
>> Guys, I fear this is descending into a non productive direction. Why
>> don't the two of you just pick up an old-fashioned phone or link up
>> via IRC or whatnot and just "talk it out". I'm sure you can resolve
>> this disagreement in a nice manner that allows us to continue enjoying
>> the good collaboration between collectd and rrdtool. Cheers!
> 
> Actually, I think the discussion is productive and I'm sure we will come
> to a conclusion everybody can agree with. I'm sorry if my more heated
> statements made this debate feel like a conflict and would like to
> apologize for the form – I stand by my arguments, however.
> 
> Regards,
> -octo