[rrd-developers] RRDCacheD - Client rewriting path

[Sebastian Harl]

Hi Tobi,

On Thu, Oct 01, 2009 at 09:05:53PM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > 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 ?

Well, I think this could best be compared to a web-server which uses a
'base directory' (usually called "document root") and serves files
relative to that. It also applies to, e.g., git-daemon, pop / imap
servers, ftp servers, samba, etc. scp is somewhat special in that
respect, as it allows access to relative path names (using $HOME as
'base directory') *and* absolute path names - imho the latter is rather
uncommon in other types of applications providing direct access to
files, though. In fact, this can be "emulated" by using the root
directory as base directory, so, imho, there is no need to provide
special support for that.

The special handling of accessing a local daemon is due to your request
to make it possible to integrate RRDCacheD into existing setups without
requiring any modifications.

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

Support for that is present already. rrdcached supports the -b command
line option to specify the base directory and uses the current working
directory as default (iirc). It's the client side only, that needs
modifications (i.e. detecting local or remote access and acting
accordingly as described above).

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

Yep - I cannot promise any ETA yet, though, but it should happen soonish
;-)

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: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20091001/d7f68b93/attachment.pgp