[OpenAFS] AFS Perl API bos & vos requirements (resend)

[Jenkins, Steven]

Thanks for the input -- I think that's very good advice.  I had been =
thinking the approach would be to copy some portions of code, and to =
re-use others, but certainly the maintenance would be an issue (although =
I don't know how often vos & bos are touched as a whole). =20

In looking at vos.c tonight, I don't see that this would be too terribly =
difficult.  Granted, I haven't looked at the source in ~3 years since I =
was supporting AFS on a day-to-day basis, so I wouldn't want to write a =
contract based on this analysis -- but that's why I'm looking for input =
from the group as a whole.  I'm assuming primarily vos.c & volint.xg =
have the necessary pieces.  The main() function is the last ~200 lines =
of vos.c, with the previous 4K what would go into libvos.a.  Virtually =
all of the main() function is calls to the cmd* API. =20

I would thus see a reasonable plan of attack as:

- put all of vos.o except the main() into libvos.a, as well as =
volint.ss.o & volint.cs.o, and then verify that vos still works.  That =
would primarily be some build hacking.
- create a cmd->xs & cmd->perl translator that will automagically build =
the APIs from the ~200 lines of main().  Worst case would be to do this =
only partially automated (or even worse, completely by-hand).

bos.c would be handled similarly from bosint.xg & bos.c. =20

There would be some real interesting/challenging work in providing the =
cmd->xs & cmd->perl (as well as et->xs, et->perl) translators).  That =
alone is a good chunk of infrastructure coding.  But on the other hand, =
that part of the code is relatively unchanging & small, so it wouldn't =
be out of the question to do it by hand.

Is that in line with your analysis as well?

Steven

-----Original Message-----
From:	Phil.Moore@morganstanley.com [mailto:Phil.Moore@morganstanley.com]
Sent:	Wed 4/30/2003 5:48 PM
To:	Jenkins, Steven
Cc:	openafs-info@openafs.org
Subject:	[OpenAFS] AFS Perl API bos & vos requirements (resend)

Well, I think this is doomed if we're not careful.

The vos binary itself implements a LOT of the logic of complex
operations such as "vos release". which you would think (or hope) is a
single RPC to a volserver, which then does everything difficult.  In
reality, there are LOTS of RPCs to the various volservers, all from
the vos command itself.

Implementing vos in the perl API would require us to re-implement a
lot of that logic, and that's a lot of code duplication.  Not good.

What I would like to see is the bulk of the vos operations moved from
vos into libvos.a, with a simple API, and then vos.c modified to use
that library and API.  Then, the perl API can be coded to the simple
API, with the bulk of the complex logic in the library.

If you don't do this first, then you're going to be fighting a losing
battle by reimplementing a LOT of the vos.c code into the XS library
that is built into perl.  That's simply a bad, unmanageable
architecture, and one we'll regret in the long run.

The same argument really applies to bos as well.

>>>>> "Steven" =3D=3D Steven Jenkins <Jenkins> writes:

Steven> (apologies on the title-less previous send)

Steven> We've been working with Norbert on his AFS Perl API, and the bos =
& vos
Steven> APIs are next on the list, so I thought I'd get input on the
Steven> design/requirements people have. =20

Steven> What particular issues or requirements do you have on either bos =
or vos?
Steven> In particular, what commands are highest priority?  What =
commands are
Steven> lowest priority?  Are there any that should simply be dropped?

Steven> My thoughts are:

Steven> Overall design: the API should match the command-line API as =
much as
Steven> possible (the current API mostly follows this, but it does =
deviate in a
Steven> few place).  If there are other interfaces exposed, that's fine, =
but the
Steven> API should match the command-line to make it easy for SAs to go =
from
Steven> commands to code.

Steven> Do bos first, primarily because this will be the first 'AFS =
internals'
Steven> development project for the student, and the bos interface will =
be
Steven> easier:=20

Steven> start with the add*, list*, and remove* to gain experience.  =
Then do the
Steven> most critical bos operations, which are: create, delete, =
restart, start,
Steven> stop, shutdown, status, salvage.  Then finish up the rest of the =
command
Steven> suite.  Most of the bos API would return a straightforward =
scalar,
Steven> array, or hash (exec is different enough, though, to make me =
wonder if
Steven> it's worth including at all).  I'm also thinking that the
Steven> install/uninstall commands are unused, so they're not worth =
providing an
Steven> interface to.

Steven> Then do vos.  I view the list* & examine as the most important, =
followed
Steven> by the release, sync*, create, delete, with the rest (eg,
Steven> backup,restore, etc) being in the third tier.

Steven> Note that this list is a first cut -- feedback will be very =
helpful in
Steven> prioritizing.