[OpenAFS-devel] Re: [OpenAFS] Documentation for fs precache
Phillip Moore
w.phillip.moore@gmail.com
Tue, 19 Oct 2010 08:32:46 -0400
--20cf30334ed1778bb30492f77d65
Content-Type: text/plain; charset=ISO-8859-1
I don't really care for hidden commands, either.
The purpose in this case was simply for backwards compatibility with
existing users of "fs precache". Strategically, I'm proposing replacing
that command with "fs getprecache and fs setprecache".
I have no idea how widespread the use of the precache feature is, but I was
assuming that a non-compatible command name change would be painful for
people currently using it. In this case, "precache" would be deprecated,
but still supported.
If we're really going to deprecate it, in addition to hiding it, printing a
warning that "precache has been replaced with set/getprecache" makes sense.
Then in a future release, you drop it entirely.
On Tue, Oct 19, 2010 at 8:07 AM, Spencer E. Olson <olsonse@umich.edu> wrote:
> I'm not really in favor of keeping commands hidden. Obviously, we all
> know that security through obscurity is not very good and for us that
> are new to administering cells, it is really helpful to see all the
> commands visible with 'fs|vos|bos|... help'--besides, who wants to read
> the man page when you can see the quick reference "guide" in 'fs
> help' :-). Normal users don't try to/can't do everything that 'fs help'
> currently lists anyways, so obscuring seems pointless.
>
>
> Spencer
>
>
> On Tue, 2010-10-19 at 07:27 -0400, Phillip Moore wrote:
> >
> >
> > Would you accept a patch that introduces two new fs commands:
> >
> > fs getprecache
> > fs setprecache
> >
> >
> > and that "hides" the precache command? IOW, precache will work, but
> > it will not show up in fs help output. This introduces a new pair of
> > get/set commands, and would give admins the ability to query the
> > value, and therefore manage it.
> >
> >
> > Alternately, fs precache can be modified to display the value when no
> > arguments are provided, instead of generate a syntax error like it
> > does right now.
> >
> >
> > There's a lack of consistency in the fs commands, but my personal
> > preference is for get/set commands when we add new features, as
> > opposed to a single command for both setting and querying something.
> >
> > On Mon, Oct 18, 2010 at 1:50 PM, Derrick Brashear <shadow@gmail.com>
> > wrote:
> > On Mon, Oct 18, 2010 at 1:45 PM, Phillip Moore
> > <w.phillip.moore@gmail.com> wrote:
> > > Another fs command I can't find any documentation for: fs
> > precache
> > > In this case, it appears that there's no way to query the
> > value. This
> > > seems like bad interface design to me. If there's a
> > mechanism for setting
> > > an important value that changes the behavior of the client,
> > there has to be
> > > a mechanism for querying that value. Otherwise, you can't
> > manage it.
> > > Write-only, read-never parameters are very bad.
> > > Looking at the code in src/venus/fs.c, it looks to me like
> > this *should*
> > > have been implemented as a pair of CLI commands: setprecache
> > and
> > > getprecache, and in fact, that should be straight forward,
> > and fully
> > > backwards compatible.
> >
> >
> > Probably. And I take blame for that.
> >
> > > Is this another bleeding edge feature that the authors
> > thought wasn't
> > > important enough to write a man page for?
> >
> >
> > No.
> >
> >
> >
> > --
> > Derrick
> >
> >
>
> --
> Mirrors should reflect a little before throwing back images.
> -- Jean Cocteau
>
--20cf30334ed1778bb30492f77d65
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><br></div>I don't really care for hidden commands, either.<div><br=
></div><div>The purpose in this case was simply for backwards compatibility=
with existing users of "fs precache". =A0 Strategically, I'm=
proposing replacing that command with "fs getprecache and fs setpreca=
che".</div>
<div><br></div><div>I have no idea how widespread the use of the precache f=
eature is, but I was assuming that a non-compatible command name change wou=
ld be painful for people currently using it. =A0 In this case, "precac=
he" would be deprecated, but still supported.</div>
<div><br></div><div>If we're really going to deprecate it, in addition =
to hiding it, printing a warning that "precache has been replaced with=
set/getprecache" makes sense. =A0Then in a future release, you drop i=
t entirely.</div>
<div><br></div><div><br></div><div><br></div><div><div class=3D"gmail_quote=
">On Tue, Oct 19, 2010 at 8:07 AM, Spencer E. Olson <span dir=3D"ltr"><<=
a href=3D"mailto:olsonse@umich.edu">olsonse@umich.edu</a>></span> wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">I'm not really in favor of keeping comm=
ands hidden. =A0Obviously, we all<br>
know that security through obscurity is not very good and for us that<br>
are new to administering cells, it is really helpful to see all the<br>
commands visible with 'fs|vos|bos|... help'--besides, who wants to =
read<br>
the man page when you can see the quick reference "guide" in '=
;fs<br>
help' :-). =A0Normal users don't try to/can't do everything tha=
t 'fs help'<br>
currently lists anyways, so obscuring seems pointless.<br>
<br>
<br>
Spencer<br>
<div><div></div><div class=3D"h5"><br>
<br>
On Tue, 2010-10-19 at 07:27 -0400, Phillip Moore wrote:<br>
><br>
><br>
> Would you accept a patch that introduces two new fs commands:<br>
><br>
> =A0 =A0 fs getprecache<br>
> =A0 =A0 fs setprecache<br>
><br>
><br>
> and that "hides" the precache command? =A0IOW, precache will=
work, but<br>
> it will not show up in fs help output. =A0This introduces a new pair o=
f<br>
> get/set commands, and would give admins the ability to query the<br>
> value, and therefore manage it.<br>
><br>
><br>
> Alternately, fs precache can be modified to display the value when no<=
br>
> arguments are provided, instead of generate a syntax error like it<br>
> does right now.<br>
><br>
><br>
> There's a lack of consistency in the fs commands, but my personal<=
br>
> preference is for get/set commands when we add new features, as<br>
> opposed to a single command for both setting and querying something.<b=
r>
><br>
> On Mon, Oct 18, 2010 at 1:50 PM, Derrick Brashear <<a href=3D"mailt=
o:shadow@gmail.com">shadow@gmail.com</a>><br>
> wrote:<br>
> =A0 =A0 =A0 =A0 On Mon, Oct 18, 2010 at 1:45 PM, Phillip Moore<br>
> =A0 =A0 =A0 =A0 <<a href=3D"mailto:w.phillip.moore@gmail.com">w.phi=
llip.moore@gmail.com</a>> wrote:<br>
> =A0 =A0 =A0 =A0 > Another fs command I can't find any documenta=
tion for: =A0fs<br>
> =A0 =A0 =A0 =A0 precache<br>
> =A0 =A0 =A0 =A0 > In this case, it appears that there's no way =
to query the<br>
> =A0 =A0 =A0 =A0 value. =A0 This<br>
> =A0 =A0 =A0 =A0 > seems like bad interface design to me. =A0If ther=
e's a<br>
> =A0 =A0 =A0 =A0 mechanism for setting<br>
> =A0 =A0 =A0 =A0 > an important value that changes the behavior of t=
he client,<br>
> =A0 =A0 =A0 =A0 there has to be<br>
> =A0 =A0 =A0 =A0 > a mechanism for querying that value. =A0Otherwise=
, you can't<br>
> =A0 =A0 =A0 =A0 manage it.<br>
> =A0 =A0 =A0 =A0 > =A0Write-only, read-never parameters are very bad=
.<br>
> =A0 =A0 =A0 =A0 > Looking at the code in src/venus/fs.c, it looks t=
o me like<br>
> =A0 =A0 =A0 =A0 this *should*<br>
> =A0 =A0 =A0 =A0 > have been implemented as a pair of CLI commands: =
setprecache<br>
> =A0 =A0 =A0 =A0 and<br>
> =A0 =A0 =A0 =A0 > getprecache, and in fact, that should be straight=
forward,<br>
> =A0 =A0 =A0 =A0 and fully<br>
> =A0 =A0 =A0 =A0 > backwards compatible.<br>
><br>
><br>
> =A0 =A0 =A0 =A0 Probably. And I take blame for that.<br>
><br>
> =A0 =A0 =A0 =A0 > Is this another bleeding edge feature that the au=
thors<br>
> =A0 =A0 =A0 =A0 thought wasn't<br>
> =A0 =A0 =A0 =A0 > important enough to write a man page for?<br>
><br>
><br>
> =A0 =A0 =A0 =A0 No.<br>
><br>
><br>
><br>
> =A0 =A0 =A0 =A0 --<br>
> =A0 =A0 =A0 =A0 Derrick<br>
><br>
><br>
<br>
</div></div><font color=3D"#888888">--<br>
Mirrors should reflect a little before throwing back images.<br>
=A0 =A0 =A0 =A0-- Jean Cocteau<br>
</font></blockquote></div><br></div>
--20cf30334ed1778bb30492f77d65--