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

[Christophe Fergeau <teuf gnome org>]

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.

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

>
> 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 ;)

Christophe