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

[Alan McGovern <alan mcgovern gmail com>]

Hey

On Fri, Feb 26, 2010 at 10:40 AM, Christophe Fergeau <teuf gnome org> wrote:

Hi,

For those that don't know me, I'm a libgpod developer.

2010/2/25 Alan McGovern <alan mcgovern gmail com>:

> 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'm not sure you need to wrap the whole API, from what I understood on
IRC, a function to get/set the variable size fields, and which tell
you which size they are would be enough.

Every struct or method which uses variable width types will need to have special handling as they can't use the simple binding method. There are a few methods we can use for this, we just have to settle on one. Everything else can be directly bound. So yes, we don't have to wrap *everything* but I've no idea what proportion of the API falls under this category.
 

> The python code is all in the
> libgpod repository, so it's possible that libgpod devs keep that up to date.

It's not too much maintained/tested, but I try to keep it compiling at least.

> 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.

Yeah, sure, no problem with shipping a C# binding with libgpod tarball
(unless it's huge/hard to build). However, someone will have to
maintain it, I don't think on the libgpod side we'll do more than
telling you when it stops compiling. If it's possible to have a few
sanity checks that are run at make check time, I guess I can try to
run these too. But don't expect the bindings to be magically
maintained/developed if they are merged upstream :) (mainly because
noone would have the knowledge to maintain these bindings over there)

That's all I'd hope for :) This way there will always be a working C# binding whenever a libgpod release is made. If the binding were kept separately in another repo it's likely that its releases would end up out of sync with libgpod and things would get messy trying to coordinate releases of the binding with releases of libgpod when the API/ABI breaks. If you have a test suite it might be possible to integrate some C# binding tests aswell to ensure that nothing obvious blows up between releases.
 

>
> 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.

Don't hesitate to tell me about your needs/the way you want to use the
API, ... If stuff is missing in libgpod, I'm perfectly fine with
adding new API or changing the existing one if it improves things for
everyone.

Nice to see you looking at libgpod ;)

Great stuff! I'm sure you'll be kept in the loop if this idea is taken up :)

Alan.
 

Christophe