[rrd-developers] RRDCacheD - Client rewriting path

[Sebastian Harl]

Hi Tobi,

On Sat, Sep 26, 2009 at 12:13:16PM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > > this also means that use of the daemon should be transparent,
> > > to use ... for file paths this means at least when running local,
> > > that the curent directory of the rrdupdate command does matter ...
> > >
> > > when running remotely this is not the case and should probably  be
> > > handled differenly ...
> >
> > Hrm ? as I might have mentioned before, I'm not a big fan of inconsis-
> > tent behavior - even it that's supposed to handle some specific cases
> > "more elegant". Imho that adds more confusion than benefit. Anyway, the
> > final decision is up to you, of course.
> 
> so maybe I did not parse your previous emails on the subject too
> closely, but can you go into detail about how you propose to handle
> the path issue consistantly locally and remotely while keeping
> rrdtool update working the same way regardles if it is working
> directly with the file or through rrdcached ? after all this is
> also about consistancy.

Well, I'd try to keep behavior consistent when talking to the daemon,
i.e. something along the lines of the new file-name syntax proposed
earlier (by Florian iIrc). In short: specify that you're talking to the
daemon and then use relative path names (relative to the daemon's base
directory).

*Personally*, I'm not sure about the benefits of being able to
transparently hide the daemon in a local setup (i.e. keeping a
consistent behavior in regard to file names when talking to the daemon
or accessing the files directly). The reasons for that are two-fold:

 a) RRDCacheD is (mostly) for large setups which (imho) will not benefit
    from that transparency. So the benefits would be limited to a small
    number of users only, while (again imho) bringing along some
    negative aspects as well (see, e.g., (b)).

 b) Introducing that transparency probably will encourage mixing direct
    and "cached" access to RRD files. This is error prone (e.g. cached
    updates will basically be lost after a direct access using a later
    time stamp), which is especially bad when it happens accidentally
    (which, in turn, is not unlikely given the many, transparent ways to
    use or skip the daemon; e.g. think about the environment variables,
    etc.). I could perfectly understand any user who's seriously annoyed
    by that.

Then again, I'm thinking of RRDCacheD as a network daemon and, thus, it
should imho be optimized for that. It might not be perfect yet, but it's
already very well suited for that purpose and I'm pretty sure that's
where we're going to.

There's a lot of "imho" in the above text, so it'd be nice to hear some
other voices on that topic but from previous discussions I got the
impressions that there are other people thinking similar to me.

I hope this could clarify my point of view.

> > > but then again, remote use of rrdcached will see some further changes
> > > with authentication and authorization anyway ...
> >
> > Yes, but (as far as I see it) that should be possible without breaking
> > backward-compatibility (since the fine-grained permission handling has
> > been included).
> 
> not breaking backward compatibility or at least continuing to
> provideing the old interface as well is always a concern for me ...

Yes, I know :-) That's why I insist so hard on getting this straight
before 1.4.

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/20090926/2279c6e5/attachment.pgp