On Sun, Jun 08, 2008 at 04:46:50PM +0200, Sebastian Harl wrote: >Hi, > >(Cc'ing rrd-users, hoping to get more feedback!) > >Please find attached a patch which cleans up the symbols exported by >librrd (and librrd_th). See the patch description for a detailed >changelog (I hope I didn't miss anything) and a short rationale for the >patch. I'm sorry that the patch got that long but I had to touch a lot >of places to implement all changes I wanted to do and keep things still >compiling ;-) > >I would really like to see this patch in the upcoming 1.3 release, so >further feedback would be very appreciated. So far, I did not do a lot >of testing but I'm going to recompile all reverse dependencies of >rrdtool (i.e. packages which build-depend on rrdtool) which can >currently be found in Debian unstable and report back after that. >However, I'm not going to be able to do much functional testing, so >that's up to you - the users of those packages! ;-) > >While creating the patch, I noticed a couple of things which I would >like some more opinions about: > > * Currently, librrd and librrd_th export the same set of symbols (e.g. > both libraries export the thread-unsafe rrd_fetch() as well as the > thread-safe rrd_fetch_r()). Is this intended? If not, I guess this > should be changed before 1.3 as well as that would else require > another SONAME bump. > > * I did not include rrd_open(), rrd_close(), rrd_write() and similar > functions in the public interface so far as they look like pretty > low-level functions which usually are not needed outside of rrdtool.
These functions should be exported since any librrdtool is pretty useless without them. Suppose i want to write a program that opens an rrd and reads one or more DS and a varying number of entries from some CF, calculates something and returns a result. Currently i would have to do alot of what fetch does to achieve this, which doesn't make sense in the light of a librrdtool. See http://www.mail-archive.com/[email protected]/msg01866.html _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
