Hi Tobi, On Mon, Jun 09, 2008 at 08:17:00PM +0200, Tobias Oetiker wrote: > > > So how about this. We export the symbols but do NOT put them in > > > rrd.h. this means that if someone wants to code, using them, it > > > will work, but it will also mean that they have to use our private > > > headers for compilation, makeing it clear that there is not > > > guarantee for support in future versions ... > > > > Frankly, I don't like that at all. I'd rather have some documented and > > correctly handled (SONAME version bump) changes than having to track > > that myself. > > > > I think, the signature of the exported functions is quite stable, so > > there should not be anything to worry about. Currently, none of the > > file-format specifications (i.e. rrd_format.h) is officially available > > to the user, so I don't think that we will run into any real backward- > > compatibility issues caused by the set of currently exported symbols. > > well the trouble is, that the only way to access the contents of > the files is that you have to have access to rrd_t which is defined > in rrd_format.h and this pulls in all of that as well,
Oops - I missed that :-/ > and since I intend to change the format to become platform indepenant, > with built in support for the old format, the low level access > functions I imagine would use an opaque handle (rrd_handle_t) which is > returned from rrd_open and can then be used to use all the accessor > functions for the rrd file to mess with it. Sounds good! > This will be for 1.4 and so exporting stuff in this direction now, > while there are no accessor functions nor an opaque data type is > not an ideal move, since it might prompt some users to start using > the lowlevel access functions befor they are properly available and > then come whining when things break with 1.4s proper accessor > functions ... Okay, so why not completely remove the low-level functions from the API again (i.e. don't even export them at all)? This would clearly state that this kind of interface is not supported right now. I still think that it's better to either completely support some interface or not support it at all - else it would create much more confusion than some properly documented changes. If I understand you correctly, your main concern is to prevent confusion rather than some possible future SONAME version change, right? If people _really_ want to use unsupported stuff and shoot themselves into the foot they can still do that by copying the rrdtool sources. While this isn't really nice, I still think that this is, in general, the best solution for either side. Sorry for the confusion ;-) 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
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
