[parted-devel] Call for organization

[Anant Narayanan]

> I agree that it's need. I'm just wondering if pyparted was _done
> right_. I'm woring if it need improvements but if it uses the a good
> way of building bindings that allow us to reuse most of code to build
> bindings for other languages as well.
> 
> We do need to think about how to do that otherwise will be a hell to
> maintain it all on the future.
> 
> Most of projects that I found doing bindings to other languages uses
> SWIG for it. What pyparted uses?
> 
> Iff it doesn't use that kinda of "framework" I'm not favoured to merge
> it.

I differ on that opinion. libparted is a system-level library and does
not deserve to use SWIG at all. The only real way to write python
bindings for something like libparted is to write it by hand in plain
old C. SWIG is great for some high-level libraries like SQLite or
GStreamer, but not for something like libparted.

Here's how I see it: we make the one-to-one bindings in plain C, like
how it was meant to be done (the "python handbook" way). The OO bindings
can then import that module and can be written in Python itself.

Agreed that this adds some maintenance overhead, we have to change the
bindings everytime an API change happens in libparted itself. But IMHO
that's something we can afford to do for two reasons: (i) API changes in
 libparted are relatively infrequent (ii) We gain performance and
general "cleanliness" of code; i.e. we know exactly what's happening. A
dependency on SWIG for something as low-level as parted is not wise.

And about language bindings for PHP; I'm all for it!
Laugh all you want, but as a developer for PHP-GTK; I think PHP is
turning out to be more versatile than it originally was; and I am not
ruling out the possibility of a GUI frontend for parted written entirely
in PHP-GTK :)

>>>> 4) Unit testing framework.
>>> Otavio's working right on this, but I don't know who will code all the
>>> tests.  It seems a lot of work.  I originally planned to pay someone to
>>> do it via bounties, but as long as we haven't received the donation I
>>> have applied for, this obviously won't work out.
>> This will be a lot of work.  I don't think it's necessary to pay
>> someone.  I think once the bulk of the test suite is written,
>> maintaining it will be less difficult.  It's the initial
>> getting-over-the-hurdle stage that's hard.

I agree with Otavio. It may seem that a lot of tests may be required;
but I know a lot of projects that do it. If we really don't get anywhere
after sometime we can think about bounties. Also, if we're lucky we'll
get a student at the Summer of Code next year :)

Cheers,

- Anant