[OpenAFS] Status of the AFS::Command CPAN module
Phillip Moore
w.phillip.moore@gmail.com
Fri, 15 Oct 2010 13:50:40 -0400
--0015175cdf7cfc9c3d0492ab7640
Content-Type: text/plain; charset=ISO-8859-1
I am the perl screen scraping king, so yes and no :-P
The AFS::Command code has been designed to work with both old as well as new
vos/pts/fs/bos output, and I would prefer to leave it that way.
If we're going to start leveraging new output formats, I would rather create
a NEW AFS::* module, so that we aren't bound to the old API at all.
On Fri, Oct 15, 2010 at 1:40 PM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:
> Over the last year there has been discussion of adding -xml, -csv, and
> other formatted text data streams. Would that be easier for you to work
> with?
>
> Obviously all of the functionality that is being performed by the
> various command line tools is in C. libadmin is the library that is
> used by the IBM AFS Server Manager on Windows. Any functionality that
> is missing could be filed as a feature request to
> openafs-bugs@openafs.org so that it is tracked somewhere.
>
> Jeffrey Altman
>
>
> On 10/15/2010 1:34 PM, Phillip Moore wrote:
> >
> > If all the functionality of vos/pts/fs/bos were available in C
> > libraries, that is precisely how I would like to implement this. In
> > fact, I've bitched and moaned about this endlessly over the years, and
> > the fact is that in order to automate AFS administration, you still
> > *MUST* use the CLI utilities for most tasks. I would love to be proven
> > wrong.
> >
> > However, even if we went this route, that would be a complete and total
> > rewrite of this code from the ground up, and will be far from trivial.
> > Let's agree to implement that in AFS::Command V3. You have obviously
> > never done any perl development with XS, either -- it's very, very
> > non-trivial and something I would not wish upon my worst enemies. I
> > spent several years trying to perfect the MQSeries API, the core of
> > which was XS wrappers around IBM C libraries, and that's how long it
> > took to hunt down and kill off the last memory leak.
> >
> > For now, V2 is merely a modernization of the current implementation, and
> > it's taken me a total of 2 days to complete, although I have maybe
> > another 2 or 3 days of improvements I want to complete. I would
> > estimate that an XS based wrapper around libadmin and friends is a few
> > months of effort, at least.
> >
> > Tactically, AFS::Command will continue to screen scrape the CLI.
> >
> > Strategically, what you propose is precisely the direction I want to go
> > in, it's just going to take some time and energy, but then, I have
> > plenty of both :-P
> >
> > On Fri, Oct 15, 2010 at 1:15 PM, Jeffrey Altman
> > <jaltman@secure-endpoints.com <mailto:jaltman@secure-endpoints.com>>
> wrote:
> >
> > On 10/15/2010 1:01 PM, Phillip Moore wrote:
> >
> > > Since AFS::Command is a glorified screen scraper, a few of the
> > > commands no longer accept lists of names/ids in order to make the
> > error
> > > handling robust.
> >
> > How about turning the implementation into something based on top of
> > libadmin instead of executing command line tools? One of the big
> > challenges preventing improvements to the command line tools is the
> fear
> > that adding to, removing from or restructuring the command output is
> > going to break tools that parse the output.
> >
> > Jeffrey Altman
> >
> >
> >
> >
>
>
>
--0015175cdf7cfc9c3d0492ab7640
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><br></div>I am the perl screen scraping king, so yes and no :-P =A0=A0=
<div><br></div><div>The AFS::Command code has been designed to work with bo=
th old as well as new vos/pts/fs/bos output, and I would prefer to leave it=
that way.</div>
<div><br></div><div>If we're going to start leveraging new output forma=
ts, I would rather create a NEW AFS::* module, so that we aren't bound =
to the old API at all. =A0=A0</div><div><br></div><div><div class=3D"gmail_=
quote">
On Fri, Oct 15, 2010 at 1:40 PM, Jeffrey Altman <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jaltman@secure-endpoints.com">jaltman@secure-endpoints.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Over the last year there has been discussion of adding -xml, -csv, and<br>
other formatted text data streams. =A0Would that be easier for you to work<=
br>
with?<br>
<br>
Obviously all of the functionality that is being performed by the<br>
various command line tools is in C. =A0libadmin is the library that is<br>
used by the IBM AFS Server Manager on Windows. =A0Any functionality that<br=
>
is missing could be filed as a feature request to<br>
<a href=3D"mailto:openafs-bugs@openafs.org">openafs-bugs@openafs.org</a> so=
that it is tracked somewhere.<br>
<font color=3D"#888888"><br>
Jeffrey Altman<br>
</font><div><div></div><div class=3D"h5"><br>
<br>
On 10/15/2010 1:34 PM, Phillip Moore wrote:<br>
><br>
> If all the functionality of vos/pts/fs/bos were available in C<br>
> libraries, that is precisely how I would like to implement this. =A0In=
<br>
> fact, I've bitched and moaned about this endlessly over the years,=
and<br>
> the fact is that in order to automate AFS administration, you still<br=
>
> *MUST* use the CLI utilities for most tasks. =A0I would love to be pro=
ven<br>
> wrong.<br>
><br>
> However, even if we went this route, that would be a complete and tota=
l<br>
> rewrite of this code from the ground up, and will be far from trivial.=
<br>
> Let's agree to implement that in AFS::Command V3. =A0You have obvi=
ously<br>
> never done any perl development with XS, either -- it's very, very=
<br>
> non-trivial and something I would not wish upon my worst enemies. =A0 =
I<br>
> spent several years trying to perfect the MQSeries API, the core of<br=
>
> which was XS wrappers around IBM C libraries, and that's how long =
it<br>
> took to hunt down and kill off the last memory leak.<br>
><br>
> For now, V2 is merely a modernization of the current implementation, a=
nd<br>
> it's taken me a total of 2 days to complete, although I have maybe=
<br>
> another 2 or 3 days of improvements I want to complete. =A0 I would<br=
>
> estimate that an XS based wrapper around libadmin and friends is a few=
<br>
> months of effort, at least.<br>
><br>
> Tactically, AFS::Command will continue to screen scrape the CLI.<br>
><br>
> Strategically, what you propose is precisely the direction I want to g=
o<br>
> in, it's just going to take some time and energy, but then, I have=
<br>
> plenty of both :-P<br>
><br>
> On Fri, Oct 15, 2010 at 1:15 PM, Jeffrey Altman<br>
</div></div><div><div></div><div class=3D"h5">> <<a href=3D"mailto:ja=
ltman@secure-endpoints.com">jaltman@secure-endpoints.com</a> <mailto:<a =
href=3D"mailto:jaltman@secure-endpoints.com">jaltman@secure-endpoints.com</=
a>>> wrote:<br>
><br>
> =A0 =A0 On 10/15/2010 1:01 PM, Phillip Moore wrote:<br>
><br>
> =A0 =A0 > Since AFS::Command is a glorified screen scraper, a few o=
f the<br>
> =A0 =A0 > commands no longer accept lists of names/ids in order to =
make the<br>
> =A0 =A0 error<br>
> =A0 =A0 > handling robust.<br>
><br>
> =A0 =A0 How about turning the implementation into something based on t=
op of<br>
> =A0 =A0 libadmin instead of executing command line tools? =A0 One of t=
he big<br>
> =A0 =A0 challenges preventing improvements to the command line tools i=
s the fear<br>
> =A0 =A0 that adding to, removing from or restructuring the command out=
put is<br>
> =A0 =A0 going to break tools that parse the output.<br>
><br>
> =A0 =A0 Jeffrey Altman<br>
><br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>
--0015175cdf7cfc9c3d0492ab7640--