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

[Neulinger, Nathan]

One thing to keep in mind is that there already is a vos library for
many of the functions in on of the subdirs. Getting rid of that
duplication would be a big plus in my book, as I know that they are out
of sync right now.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Phil.Moore@morganstanley.com=20
> [mailto:Phil.Moore@morganstanley.com]=20
> Sent: Friday, May 02, 2003 9:28 AM
> To: Jenkins, Steven
> Cc: Norbert Gruener; OpenAFS Info
> Subject: RE: [OpenAFS] AFS Perl API bos & vos requirements (resend)
>=20
>=20
> >>>>> "Norbert" =3D=3D Norbert Gruener <nog@MPA-Garching.MPG.DE> =
writes:
> >>>>> "Steven" =3D=3D Steven Jenkins <Jenkins> writes:
>=20
> 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.
>=20
> Norbert> Do you think that you can convince the OpenAFS developers to
> Norbert> do that step ?  If so, I will be happy.
>=20
> 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.
>=20
> 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.
>=20
> Strategically, this would also make it easier to developer similar
> management interfaces in other languages like Python and Ruby.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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).
>=20
> 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...
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20