[rrd-developers] RRDCacheD - Client rewriting path

[Tobias Oetiker]

Today Sebastian Harl wrote:

> Hi Tobi,
>
> On Wed, Sep 30, 2009 at 10:53:31PM +0200, Tobias Oetiker wrote:
> > what I would do now, is this:
> >
> > * If the client is called on a local daemon  with a relative
> >   pathname, the path name gets rewritten.
> >
> > * If the client is called on a remote daemon with a relative path
> >   name, the client aborts with an error since rewriting the path
> >   for remote calls makes not sense.
>
> Basically, that sounds like a fair compromise to me. However, I'd go for
> not allowing *absolute* path names. If we're using the base-directory
> approach in the future (for remote access), then absolute paths won't be
> allowed in the future. Relative path names will simply be sent to the
> server (without being rewritten) and they are treated as relative to the
> respective base directory. I.e. there's gonna be no need to know what
> file system layout the daemon uses. Do you agree with that?
>
> I hope to find some time to work on that within the next few day ?
>
> Just to make it clear, let me summarize what I'm thinking about:
>
>  * relative path:
>
>    - when accessing a local daemon (i.e. the daemon address specifies a
>      unix socket), the path name gets rewritten to allow transparent
>      integration into existing solutions (no change)
>
>    - when accessing a remote daemon, the path is not touched at all to
>      let the daemon use its base directory
>
>  * absolute path:
>
>    - local daemon: no change
>
>    - remote daemon: abort

I understand what you mean, to what other unix tool are you
modeling this ? rcp/scp ? In that case, I think rrdcached should
know its 'base-directory' as well to enable things to work in a
sensible way in 1.4 already ...

> > in 1.5 there would be a special rrd file name syntax to specify
> > whether you mean to access a local rrd or one managed by a daemon
> > be it remote or local.
>
> Great :-) Putting that on top of the current approach (and marking the
> current approach as obsolete) would then be a backward-compatible change
> and allows for a transition period to let users migrate to the new
> scheme.

you are going to create a patch for the pathname thing ?

cool

cheers
tobi


> Cheers,
> Sebastian
>
>

-- 
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