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

[Sebastian Harl]

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

-------------- 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/20080610/003551dd/attachment-0001.bin