Re: [Banshee-List] Proposal to move Banshee to libgpod



Just a quick update, the python bindings do indeed generate their own C wrapper which does the time_t mangling so that python can consume libgpod.

However, we won't be able to reuse the wrapper C library that python creates, we'll have to create our own wrapper C library (though I do think this is less than ideal ;) ). We can probably use swig for this aswell - if it works for python it'll work for us. Wrappers for everyone!

So, who knows swig enough to want to try use it to generate our wrapper?

Alan.

On Thu, Feb 25, 2010 at 5:26 PM, Alan McGovern <alan mcgovern gmail com> wrote:
This is a slightly tricky task from a technical perspective. The C API exposes both enums and time_t types. These are hard to bind from C# as they are of unspecified width and type. We'd have to write a C wrapper which exposes pretty much the same API except using int64_t/gint64 in place of time_t and also  expose the enums as something of specified width (int32_t/gint32 ?).

I believe the python binding generates its own C binding. It's possible their binding was created to combat this issue, if so we can just re-use theirs. Anything python can wrap, .NET can wrap. Someone would either have to look through the python wrapper C binding or ask the developer of that binding why they generate their own wrapper. The python code is all in the libgpod repository, so it's possible that libgpod devs keep that up to date. If we can re-use their binding, then it's quite possible we can get a P/Invokable wrapper with zero maintenance on banshees part, which would be great. Alternatively, maybe upstream would be OK with putting the C# binding code in their repository and keeping our C binding (if we need one) up to date. It's worth asking. At the very least we'd be able to get notification when something changes which requires the C binding to be updated.

Once we have a P/Invokable wrapper around libgpod, things should be fairly peachy. Someone more familiar with libgpod can comment on how easy its API is to work with and how easy it would be to integrate with banshee itself.

Alan.

On Tue, Feb 23, 2010 at 11:28 PM, Chow Loong Jin <hyperair gmail com> wrote:
Hi all,

Recently there have been discussions on #banshee about getting Banshee to move
to libgpod from its current ipod-sharp/podsleuth usage. I am in favour of this,
if it ever takes place, since ipod-sharp/podsleuth is beginning to get rather...
dated, and doesn't really does seem behind time as there are several popular
models of iPods not supported, such as the iPhone/iPod Touch, some Nanos, among
others, and it still relies heavily on HAL, which is deprecated.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]