[OpenAFS] AFS::Command Perl Modules (was: 'vos examine', 'Last update' and date format)

[Phil.Moore@morganstanley.com]

>>>>> "Phil" == Phil Moore <Phil.Moore@morganstanley.com> writes:
>>>>> "Derrick" == Derrick J Brashear <Derrick> writes:

Phil> I also looked into implementing AFS::VOS as an XS module, but
Phil> felt that the architecture of the code would be unsupportable,
Phil> since way too much of the complex logic in vos.c would have to
Phil> be replicated in the XS code, leading to parallel management of
Phil> the two code bases.  I am more than willing to be proven wrong.

Derrick> Suggest an API and rewrite vos to it.

I spent some time looking into that, and even if we *do* make it easy
to write this code as an XS module, that will mean the resulting perl
API is only useful to sites that have upgraded to the latest and
greatest OpenAFS release, or at last have the necessary librariesd
compiled and available.

IOW, sure, that can be done, but (a) its non-trivial, and (b) its
strategic.  I need a solution I can use today, with existing AFS
installations (Transarc *or* OpenAFS).

The approach I've taken will work with the existing commands, dating
back to AFS 3.3a (not that I am going to support, nor encourage such
use, but it should work).

Unless we radically change the vos output, this approach will prove to
be perfectly workable, and since myself, and several others have built
production systems on APIs like this, I think the concept has proven
itself.

Even if we *do* radically change the vos output, the code can adapt
(unless vos starts spitting out encoded binary nonsense, in which
case, it'll just be hard ;-)

Phil> The code I have takes a different approach, and is actually a
Phil> re-write of an old perl4 (yes, perl *FOUR*) API I wrote, 10
Phil> years ago.  The text output from vos, fs, etc is deterministic,
Phil> and relatively straight forward to parse (well, not trivial, but
Phil> since I had the parsing code already...).

Derrick> You know Jeff Hutzelman already did that, right? Look in
Derrick> src/tests in OpenAFS and you'll find those perl modules.

No, I wasn't aware of that code at all.  I'm suprised I missed them.
Looks like we'll have more options that I originally thought.

Maybe Jeff can chime in on the level of support for this API?  It
appears to exist only to run the tests themselves, and doesn't get
installed in a standard manner.  That makes it a bit hard to work
with.  The README.afstools says to go to grand.central.org, but I
can't find any mention of the code there.