[rrd-developers] it exposes too much ...

[Sebastian Harl]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080609/eea5052e/attachment.bin