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

[Sebastian Harl]

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.

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

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

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?

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

>   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 … ;-)

> 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

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-users/attachments/20091106/0f4ed77e/attachment.pgp