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