[rrd-developers] RRDCacheD - Client rewriting path

[Sebastian Harl]

Hi Kevin, et.al.,

On Sun, Aug 09, 2009 at 03:44:41PM -0500, kevin brintnall wrote:
> On Sat, Aug 08, 2009 at 12:22:26PM +0200, Yann Jouanin wrote:
> > It seems the behavior of RRD client when using RRDCacheD can make trouble
> > when using RRDCacheD on another host than the one where using client.
> > 
> > The translation between relative path and absolute path is done in client
> > code (rrdc_flush) while it should only be done by the server.

> The client must convert to absolute path because the daemon has no idea
> what the cwd is of the client.  This is true even when the client and
> server run on the same machine.  i.e.:
> 
>     rrdtool update 1.rrd N:1:2
>     cd elsewhere
>     rrdtool update 1.rrd N:1:2

Hrm, I'm not sure that I agree with that. Why does the client's current
working directory matter at all to the server? Think about other ways of
remote access to files - all of them use some kind of base directory
that's used whenever relative path names are specified: scp uses $HOME,
Apache uses the document root, git-daemon supports a base path, etc. So,
I think that by following the principle of least surprise RRDcacheD
should behave like that as well. Let people think about $HOST:1.rrd
instead of 1.rrd (where $HOST might be remote or local) - we're
referring to a file on some $HOST after all …

I agree that it's not quite as obvious when using RRDcacheD locally
only (and I guess that's why it's currently implemented that way, since
that was the very first approach). Then, you'll actually see the files
in your local file system, so from a user's POV, $CWD probably does
matter. So, maybe the question is: Is RRDcacheD supposed to be a
networking daemon or rather some service that just happens to support
remote access as well because it was easy and convenient to implement
that as well? I'd probably go for the former and I'd suppose that this
is going to be the, by far, more common use case.

Then again, I guess you can find a few more pros and cons for either
way. So, maybe the actual problem is that too much magic has been put
into the way the daemon may be enabled (on the client side). By allowing
to hide the fact that, in fact, you're accessing some daemon (e.g. by
specifying an environment variable) it might not be obvious what's going
on and thus either way might be confusing for a rather large fraction of
users. OTOH, users who hide that fact have to do so explicitly, so they
should know what they are doing. So, again, I'm in favor of not letting
the client rewrite any path names.

Just my 2 ¢.

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/20090810/fd8269d5/attachment.bin