[rrd-users] rrdtool 1.4.x without graphing support?

[Tobias Oetiker]

Hi Sebastian,

Friday Sebastian Harl wrote:

> Hi Tobi,
>
> On Thu, Nov 05, 2009 at 11:56:10PM +0100, Tobias Oetiker wrote:
> > Today Sebastian Harl wrote:
> > > On Thu, Nov 05, 2009 at 05:53:20AM +0100, Tobias Oetiker wrote:
> > > > Yesterday Ulf Zimmermann wrote:
> > > > > Anyone got an idea how much work would be involved to build/patch
> > > > > rrdtool 1.4.x to remove graphing support? Library dependency for
> > > > > EL4 is just hell at this point. And as I need librrd, I am not
> > > > > sure how far I can work with a static build to work with collectd
> > > > > together.
> > > >
> > > > you may want to try the appended patch.
> > >
> > > > +if BUILD_RRDGRAPH
> > > > +RRD_C_FILES += rrd_graph.c	\
> > > > +	rrd_graph_helper.c	\
> > > > +	rrd_xport.c	\
> > > > +	rrd_gfx.c \
> > > > +	pngsize.c
> > > > +endif
> > > [?]
> > >
> > > NB: RRD_C_FILES is later used to specify the source files for librrd.
> > >
> > > In case this patch is supposed to be included in RRDtool, please note
> > > that it provides an easy way to build RRDtool with a different API /
> > > ABI. Hence, it requires a different SONAME version (or even better: a
> > > different SONAME -- which would be easier to implement as well).
> >
> > this patch is not the library split or anything like this ... it
> > is simply an attempt to help ulf ...
>
> That's what I though -- I just wanted to make sure we don't miss this
> issue ;-)
>
> > note that there are already similar configure options for libdbi
> > which enable/disable functionality without changeing the library
> > version ...
>
> Darn, I did not notice that so far :-/
>
> This is not a good thing either (imho). One could argue that taking care
> of appropriate SONAME version changes is the responsibility of distrib-
> utors. However, this will create problems for users if done differently
> on different distributions.
>
> > after doing this initial version, and thinking about it I think
> > adding stub versions of the public graph functions which set
> > rrd_error when called would be a nicer variant ... leaving the
> > library interface in place ...
>
> This would keep the API unchanged but it *does* change the ABI (the
> semantic of some functions would change -- dramatically even), thus
> still requiring a SONAME version change.

well this is a fundamental problem since configure options CAN
change how a program works, also the mmap option comes to mind ...
I guess this is not easily solved in a way that makes everybody
happe, so I want to keep it to API consistancy. If the user compiles
rrdtool in a particualar way then the program does behave
differently but this does not come as a surprise ...

obviously packagers for distributions should take care of keeping
things consistant ...

> > > Anyway, rather than including this (imho) somewhat hackish way, I'd
> > > rather go for splitting the library as discussed before (librrd /
> > > librrdgraph). I'm willing to provide a patch for that targeted at
> > > RRDtool 1.5 (it will probably require a SONAME version bump, thus, it
> > > should imho not be included in 1.4 -- I'd also provide patches for
> > > reverse dependencies known to be affected by that).
> >
> > yes, a split of the library for 1.5 would be cool ... I would
> > propose the following split:
> >
> >   librrdclient - access to rrdcached functions - no deps
>
> Sure, why not ?

I would love to see a core of rrdtool functionality without library
dependencies this makes it easy to compile the beast for small
(embeded?) systems ...

> >   librrdcore - core rrdtool functions (create/update) - no deps
>
> You've been talking about an API-redesign scheduled for 1.5 -- any
> specific plans for that yet?

not yet ... but the general idea is to have a new api (more c-ish)
and then provide the classic api on top. My main focus for 1.5 is
the data format though ...

> Also, as of now, this lib would depend on libdbi. If we want to split
> that out as well, librrdcore would still depend on that unless
> rrd_fetch() would be split into two functions. Another approach would be
> to introduce "backend-drivers" (i.e., one handling files, one handling
> SQL databases thru dbi, etc.). Those drivers could then be loaded
> dynamically by rrd_fetch(). IIrc, somebody has proposed a "virtual file-
> system layer" some time ago -- what happened to that?

have not heard anything from the guy ... I guess this might tie in
with the cached access ..

> >   librrdcached - rrdcached  - glib
>
> What's that supposed to include and what purpose is it going to serve?
> Do you want to make rrd_daemon.c:main available thru the/a library? I
> don't see any benefits from that.

you are right

> >   librrdgraph - graphing - cairo pango
>
> That's the most important one ;-)

:-)

> >   librrd - compat layer - librrdclient librrdcore librrdcached librrdgraph
>
> I'm still unsure about details like "does that change the ABI?", etc.
> (see a previous E-mail in a different discussion on that topic) but, I
> guess, it might make live a bit easier for users who compile stuff them-
> selves (rather than having their distributor take care of that), so
> (*shrug*) why not ? ;-)

there are such people :-)

> > configure could then automatically disable the bits of rrdtool
> > which can not be built due to libraries missing
>
> NB: "bits" as in "single libraries", rather than features of one library

yep

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900