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

[Phil.Moore@morganstanley.com]

>>>>> "Chas" == Chaskiel M Grundman <Chaskiel> writes:
>>>>> "Steven" == Steven Jenkins <Jenkins> writes:

Chas> This seems somewhat poorly thought out. The stuff in vos.c is
Chas> very much front-end oriented. The functions which take only a
Chas> struct cmd_syndesc *as are command parsers for vos. They are not
Chas> library functions. They call some utility functions to set
Chas> things up, and then one of the UV_ or VLDB_ functions from
Chas> libvolser.a/libvldb.a to do the actual work. I suppose that it
Chas> might make sense to put things like WriteData, DumpFunction, and
Chas> their dependencies into a library. but not the rest of
Chas> vos.c. (if you were considering calling GetServer or
Chas> cmd_Dispatch from xs code, then, IMO, you aren't really writing
Chas> a perl api for the volser library, but something else. There are
Chas> serious issues with the volser client code, but this isn't one
Chas> of them)

Steven> Is your concern a naming issue?  Ie, would you be more
Steven> comfortable to see the library named libvos_client.a?

I think his concern is the same as mine -- the library name is
irrelevant, the way you were planning on splitting the code is not.

The problem is far more complex than just ripping main() out of vos.c,
and turning that code into a library.  As soon as you l.ook at the
code, you'll see that each of the routines is basically a wrapper
around VLDB RX calls, and the return values are just pretty printed.

What you need for building a perl/python/ruby API (I'm thinking ahead
:-) is a library that returns data structures, not prints stuff on
stdout.

So this really involves a lot more work than you originally implied.

Its a LOT more than just cut/paste and splitting existing routines
into seperate files.  The code will need some serious rearchitecture.