[OpenAFS] building swig based interfaces

[Gémes Géza]

2013-09-01 14:57 keltezéssel, Gémes Géza írta:
> Hi,
>> On 9/1/2013 6:27 AM, Gémes Géza wrote:
>>> Hi,
>>>
>>> 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 
>>> interface
>>> 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
>>> (https://lists.openafs.org/pipermail/openafs-info/2012-September/038684.html). 
>>>
>>>
>>> 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!
>>>
>>> Cheers
>>>
>>> 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?
>
> Cheers
>
> Geza Gemes
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
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.

Cheers

Geza Gemes