[rrd-developers] [PATCH] rrd_client: Do not rewrite path names when accessing remote daemons.

[Tobias Oetiker]

Hi Sebastian,

Today Sebastian Harl wrote:

> Hi again,
>
> On Wed, Oct 07, 2009 at 11:36:42AM +0200, Florian Forster wrote:
> > Wouldn't it be *much* simpler to simply let the user chose what to do?
> > I. e. forbid absolute paths by default and only if the
> >   --i-know-what-i-am-doing-and-really-need-absolute-paths-please
> > option is given accept absolute paths.
>
> Just to specify that further: This switch would define the behavior of
> *any* connection to the daemon, no matter if local or remote. Absolute
> path names would, obviously, always be relative to the root directory -
> no matter what kind of base directory has been specified (the daemon
> *always* uses a base directory - if not specified on the command line it
> defaults to /tmp currently, so treating that differently if this has
> been specified on the command line does not make sense). It should be
> noted that absolute path names may still be rejected if they point
> outside the base directory and -B has been specified on the command
> line. Thinking about that again, the -B option basically already
> provides the suggested behavior, so there should not be the need for
> another option. Relative path names would always be treated relative to
> the base directory.
>
> Anyway, I've just noticed that this is in fact a bit orthogonal to the
> *client* side path name translation, we've talked about previously. I've
> just talked to Florian about that on IRC and we both agreed that some-
> thing like that should in fact not be done in the library at all but
> rather (if it really needs to be there) belongs into the rrdtool binary.
> The purpose of the library is to provide an abstraction and API over the
> network protocol. Any further usability features, especially those that
> are highly controversial like this one, should be left out of it. So, if
> that feature should be preserved, it should be implemented in rrdtool
> and possibly be configurable through a command line option - again, this
> should be disabled by default imho.

'the library' as it stands is all there is to rrdtool, rrdtool is a
is a realy thin wrapper around the library. one might call it
'shell bindings' ... the design idea is for it to behave the same
as the bindings for all the languages ... obviously there are some
perks for language bindings like better access to return values and
such ...

the 'path rewriting' has to happen in the library because
applications that use rrdtool are accessing its functionality
through a variety of different bindings ... they should all behave
the same and be able to use the daemon for local caching
transparently by setting the apropriate environment variables ...

I imagine that we can do a more c-like library interface 'below'
the current one and then implement the current functionality on top
of it for legacy application and language bindings ... then I agree
that the path magic should happen in the second layer ... but again
this is not going to happen now ... think 1.5 ...

cheers
tobi




-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900