[OpenAFS] building swig based interfaces
Sun, 01 Sep 2013 19:00:05 +0200
2013-09-01 18:55 keltezéssel, Brandon Allbery írta:
> On 9/1/13 12:49, "Gémes Géza" <firstname.lastname@example.org> wrote:
>> 2013-09-01 14:57 keltezéssel, Gémes Géza írta:
>>> 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?
>>> 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.
> The main point here is that the interfaces you want to use are not
> actually usefully in libraries for you to bind to. Libadmin is
> unmaintained and out of date and nobody knows if it even works at this
> If you really want to do this, either you wrap the command line utilities,
> or you get to redesign those utilities so that their functionality is in
> bindable libraries. Don't try to make a parallel library like libadmin
> was; it'll just bitrot the way libadmin did.
Okay, then should wrap around the command line tools then, in the hope,
that some day they will get rewritten to use a library I (or someone
else) can use? BTW. I'm fine wit it for now.