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
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers