[OpenAFS] building swig based interfaces
Sun, 01 Sep 2013 18:49:03 +0200
2013-09-01 14:57 keltezéssel, Gémes Géza írta:
>> On 9/1/2013 6:27 AM, Gémes Géza wrote:
>>> I've decided to start a project for building a swig based python
>>> interface for afs commands/functions. The advantage is that a swig
>>> interface can be further used for creating interfaces for other
>>> languages. Currently I know about only one limited python-afs interface
>>> which calls the afs binary commands instead of implementing an
>>> to the C code (https://github.com/openafs-contrib/afspy). On the other
>>> hand the (to my knowledge) only interface: AFSPerl
>>> (http://cpansearch.perl.org/src/NOG/AFS-2.6.3/) uses suboptimal
>>> interfaces making it incompatible with 1.6.x and 64 bit
>>> So if you can give me some pointers about where should I look in the
>>> openafs source for the declaration of different functions? My first
>>> guess would be the files in libadmin, but I'm probably wrong :-(
>>> Thank you in advance!
>>> Geza Gemes
>> In theory you would be correct that libadmin would be the proper place
>> to look. libadmin provides a library interface to a subset of the
>> various command sets and was used by IBM to build both the Java
>> interface and the AFS Server Manager and User Manager applications on
>> Windows. Unfortunately, neither the Java classes nor the Manager tools
>> have been well maintained during the OpenAFS era. As libadmin had no
>> consumers it too did not receive much attention and all of the bug fixes
>> and functionality improvements which were added to the command line
>> interfaces were not applied to libadmin.
>> The PIC vs non-PIC library issues described in the 2012 mail thread
>> apply to libadmin as well as the rest of the code base. It is an
>> architectural issue. The perl-AFS for 1.4 as implemented simply could
>> not work without PIC versions of all dependencies. These are available
>> in current 1.6 releases but not 1.4 releases.
>> A broader set of long term problems for perl-AFS and any SWIG interface
>> is the code called by the command line tools is not guaranteed to be
>> thread safe nor are there any interfaces that are guaranteed to be
>> stable across OpenAFS releases. An additional problem is that if the
>> language supports loading and unloading of modules, the OpenAFS RX
>> library is not safe to unload as it cannot properly shutdown its worker
>> threads and cleanup its global state information.
>> The goal of a stable, thread safe set of bindings for Python, Perl,
>> Java, and perhaps Ruby and Powershell is admirable one. There are a
>> couple of approaches that can be taken:
>> 1. Start by defining the SWIG interface in terms of the functionality
>> that will be exposed to callers but implement it in terms of the
>> command line interfaces. This will permit the language binding
>> to be reviewed and obtain real work use.
>> 2. After the SWIG interface is considered stable begin to work on the
>> OpenAFS command line tools to refactor their sources into a thread
>> safe library that isolates the user interface (input, output,
>> error handling, logging) from the operational functions.
>> 3. As each library is ready for use substitute the command line calls
>> with the C library functions while maintaining the stability of
>> the language specific binding.
>> Another approach would be to back port all of the changes to the command
>> line tools to libadmin but I do not believe that project would be
>> worthwhile. In order for the libraries to be maintained moving forward
>> they have to be used within the OpenAFS source tree and that effectively
>> means they must be used by the command line tools.
>> I hope this is helpful.
>> Jeffrey Altman
> Sorry if it sounds nitpickering, but I want to be sure, I didn't
> misunderstood your idea.
> In a nutshell your proposal for me is to design a swig interface
> around exec calls for the existing binaries (like bos, vos, fs, etc.)?
> And after having a stable interface try to modify the backend part of
> the interface, to call into the underlying code?
> Geza Gemes
> OpenAFS-info mailing list
Sorry if I wasn't clear with my intentions. I plan to have a python
interface, where all the parts (volumes, pts entries, cache, etc) would
be represented as objects. So basically I plan to have a few classes
like volume, pts, cache, bos, with properties reflecting their state and
methods for manipulating them.