Has there been any discussion about splitting off the media device support into a separate library? The idea behind this would be that banshee, rhythmbox, xmms2, whatever can use the library and then everyone benefits from the same media device support.  This would cut down hugely on the code replication between projects. I believe there are bug requests in every major media player for several lesser media players. This would also benefit from using hal to autodetect when a device is connected. This could be one of the goals for amaroK 2.0. Kind of like M$'s play for sure stuff. Except done right.

I outlined something like this in the rhythmbox bugzilla. http://bugzilla.gnome.org/show_bug.cgi?id=340648

Any thoughts?

Well Banshee can't even use the device-specific libraries because they're in C#.

In general I think our technologies are too different and this library is working at too-high a level. HAL is a good example of this, we get an abstract layer to HAL support from KDE already. It would have to be reimplemented in the proposed library.

Our devices use the readily available plugins to access the devices (think libgpod, libifp, libnjb...)

I know that libgpod and libnjb are there, and I would use them in a library. The issue as I see it is that there are dozens of small media players that don't use any normal library. Once someone gets one and writes a library, it has to be reused for every media player. A library as I have suggested, would allow the media players to just get support when support for the media device is added to the library without any further work. As for banshee, bindings could be written for C, C++, C#, Python, Ruby, whatever your favorite language is. For example, when a wigettron 3000 comes out, a dev adds support for the wigettron to the library and releases a new version. Ubuntu (for example) updates it's packages, and rhythmbox, amaroK, banshee all work with the wigettron without even knowing that it existed.

This is way beyond the scope of amaroK.

You propose to create a libmetamediadevice, which sounds good in theory, but I think would have a lot of shortcomings in practice.

In any case, its not something amaroK has any reason to implement, it may be nice to use if it ever came about however.