401 - Beagle--Bluefunk-and-Plugin-Systems

Over the weekend, I did a basic implementation of a Beagle source for Bluefunk. What this means is that you can query Beagle with the name of an artist, song or album and Bluefunk will run a Beagle query for you. There is a screenshot at the Bluefunk site.

It appears that the 0.0.5 release of Beagle doesn’t index music in the same way as a CVS version I was using for testing. Unfortunately the release version doesn’t seem to index the data from the files, it just indexes the file names. The CVS version is also not building for me at the moment, which makes things worse. This means that the Beagle source probably isn’t that useful unless you happened to have the CVS version I used to have! Hopefully the Beagle team will release a 0.0.6 release that fixes these problems.

Having a Beagle source means is that Beagle is required to use Bluefunk. As Beagle isn’t exactly in wide usage, I’ve decided to start work on the Bluefunk plugin system. The first aspect to be moved to plugin based architecture will be the sources. This means that the Beagle source can be a downloadable plugin, rather than imposing prerequisites for the main package.

Having pluggable sources should also make Bluefunk more readily extensible. A nice source would be one that displays the content of iTunes-style shared playlists within Bluefunk, or perhaps can share libraries over a network.

After sources, hopefully it will be fairly easy to add in support for pluggable audio-backends, such as a Xine backend. For the Mac port it would be nice to have a native <abbr title=’User Interface’>UI</abbr>, rather than using Gtk+. This will probably necessitate a pluggable <abbr title=’Graphical User Interface’>GUI</abbr> layer. I suspect this will be a lot more difficult than either sources or audio-backends, as the <abbr title=’Graphical User Interface’>GUI</abbr> is far more integrated with other code than sources or backends.

I’m not sure that having a <abbr title=’Graphical User Interface’>GUI</abbr> abstraction on the different toolkit level is a good idea, because it makes other plugins very hard to do. For example, each source plugin needs to provide a <abbr title=’User Interface’>UI</abbr> to allow the user to use it. Having to provide this on multiple platforms would be hard and dissuade people from creating the plugins.

Plenty of food for thought, at any rate.

.:.