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

[Phil.Moore@morganstanley.com]

>>>>> "Norbert" == Norbert Gruener <nog@MPA-Garching.MPG.DE> writes:
>>>>> "Steven" == Steven Jenkins <Jenkins> writes:

Steven> - put all of vos.o except the main() into libvos.a, as well as
Steven>   volint.ss.o & volint.cs.o, and then verify that vos still
Steven>   works.  That would primarily be some build hacking.

Norbert> Do you think that you can convince the OpenAFS developers to
Norbert> do that step ?  If so, I will be happy.

Steven> Anyone can submit patches, and assuming that my
Steven> quick-and-dirty analysis is correct, I don't see any major
Steven> roadblocks to making that change.  Someone (eg, Phani or
Steven> myself) will simply need to spend a few days to get that done.

Yeah, but not all patches get accepted, but in this case, this seems
like a no-brainer for the most part.  There's no functionality lost,
but we simply need to make sure the libvos.a has a sane API that we
can easily link with from perl.

Strategically, this would also make it easier to developer similar
management interfaces in other languages like Python and Ruby.

However, I think this is a lot more complex than just splitting the
vos.c source up, though.  The functions you want to export, such as
ListVLDB() for example, don't return *anything*.  They simply print
out the results to stdout.

You also need a scheme for passing back the error messages in a sane
fashion, too.   Again, printing to stderr won't cut it -- you want
something like libresolv's herrno, I would think.

I think you need to take routines like ListVLDB() and split them in
two.  You need a function in libvos.a that does the same thing, and
passes back a data structure with the VLDB information, and a function
in vos.c that calls that routine, and basically just pretty prints the
data structures.

The perl API will then be able to take those data structures from the
C API in libvos.a, and turn them into perl data structures (array of
hashes, each hash representing a single VLDB entry, and then more
structure to that hash as needed).

Now, passing back complex data structures is fine, but it would also
make sense to give some thought to an object namespace in perl for all
of this data, so that we can abstract it a bit, but we can tackle that
once we have a libvos.a that provides us with the raw data we need.
One step at a time...