Hi Tobi, On Mon, Jun 09, 2008 at 06:07:42PM +0200, Tobi Oetiker wrote: > I am having second thoughts ... with all the lowlevel functions > exported, we are runnning into a maintenance nightmare as fahr as > backward compatibility is concerned. A futere rrdtool version (1.4) > which comes with a new fileformat, would have to emulate all these > lowlevel interfaces ...
All of those functions should be independent of the file-format (in fact, the functions rather abstract from the actual file format used). So, when the file format changes all of those functions should stay in place but the _implementation_ has to be adopted to the new format. Am I missing something here? If some user decides to manually mess with file internals, it's imho up to her to take care of file-format changes. I would highly discourage anyone to do so anyway - the library should provide appropriate functions to access abstracted logical parts of the files. Currently, such functions are not available but I think Bernhard's suggestions are the right step in that direction. Furthermore, it can be argued that file-format changes are reason enough to bump the SONAME version (that is, taking care and documenting API/ABI changes). I'm not entirely convinced about that so far though (just a few days ago, I disagreed entirely ;-)) but, by now, I see that it might make some sense to do so. > 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. So, imho the real concern in that respect is the set of officially available data-type definitions and I think that we're currently hiding all parts which should cause any trouble. 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
