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

[Phil.Moore@morganstanley.com]

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" == 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.  

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: 

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.