Hi... Welcome to what would eventually become the fryTunes website. Now it's pretty much just a place holder, which says we exist, and we were not dead at the time of writing. (See the CVS for when that was)

fryTunes (rumors say it means free iTunes) is an effort to provide a replacement for the organizational aspects of Apple's iTunes. We hope to create a system which will be capable of mimicing iTunes, and providing full compatibility to all it's media management features (and more, ofcourse, but tha'ts obvious). Basically, fryTunes will try and help you sort your music collection. fryTunes should be able to rip CDs for you, and keep the output sorted somewhere (plans for modularity of this have been made - could be an 'iTunes Library' compatible folder structure... Could be a RDBMS database accessible through SQL, and so forth). It should help you manage song meta data easily. It should be able to manage music streams. The basic concept is to replicate and enhance the 'behind the scenes' of iTunes.

fryTunes has been (and still is being) designed slowly and carefully, trying to weigh out all options. As I (Yuval) see it, the main problem of the various music management suites are that they're too bloated, too monolithic, and non reusable. The whole program will be implemented in a plugin based interface, somewhat like a jigsaw puzzle. Parts should coexist, even if they do the same job (a decoder plugin for OGG Vorbis should be available at the same time that one is available for MP3, not either or), but also have the capability to provide drop in replacement (SQL data store instead of plain files on a file system). The plugin interface will be implemented as a meta objects, using the perl package namespace, and some AUTOLOAD wizardry. In general it should be well behaved within the context of perl classes, allowing a reasonable learning curve, aswell as future enhancements (multiprocessing could be enabled transperrantly using on demand loading partitioned between threads. It looks as if this can easily be a drop in enhancement, provided plugins are well behaved. Imagine all the computers in encoding a CD at the same time, using a farm of fryTunes processes sharing data via RPC. I'm getting carried away). The point is, fryTunes tries to walk slowly, keeping from where others have gone wrong, and trying to think up every single possibility we can, and make sure we don't do anything that might make it impossible.

Briefly - first will come the API. A perl module, to be released on CPAN: Object::Meta::Plugin. Find a better name, and I'll change it. This will be the documentation and implementation of an object capable of creating itself from various fragments, and using other instances of itself as plugins. It should be quite simple, and provide a simple means of connecting everything, without changing much over the life of the project. Be it the grammer. Version 0.01 came out Nov 29th, 2003
After the API fryTunes's specifications atop it shall come. This will be a set of common object specifications - things, if you will, that have to do with music. These objects are what allows the plugins to interact well - a song object will be made up of meta data objects, parent objects which encapsulate it (album, side / cd number, internet stream and time stamp, etc), and media objects, pointing to several versions (the same song imported from two CDs, or one lower quality version for your portable player), aswell as versioning info (live, alternate take, etc). We basically define the material we're going to operate on, so that plugin writers can know what to expect, and how to talk with each other. Be it the vocabulary.
After this specification is written completely, examined, and turned over several times, a basic implementation wrapping things up will be made. First, the cosmetic utility plugins - the plugin loader plugin, the configuration file plugin, and so forth - plugins which should be part of the base distribution, will be written. These plugins will then create an API which is somewhat less abstract or generalized, and provides the features of an actual application, not a meta object. They will probably be also reusable in different projects.
Last, but not least, there'll be the actual meat of fryTunes. We'll start with a simple plugin which plays data with madplay, or mpg123, a lame based CD ripper, and an interface to the iTunes library (using Mac::iTunes). The interface part will come next - a web interface, to provide access similar to what mldonkey has, as well as a simple daap front end so that iTunes can be used to play things from a remote fryTunes process, not just the files it worked on.
Hoping the project will reach some sort of beta grade maturity by then, and Object::Meta::Plugin will be getting stable, we'll probably start writing more complex plugins, as well as some enhancements to the core, like RPC glues, multi tasking support, and so forth.
For now, if you'd like to see some ideas, stubs, and so forth, check the cvs repository - I will probably be posting things there pretty soon.

If you'd like to help, come join us on fryTunes's SourceForge home.

Object::Meta::Plugin is a base class for a simple plugin, which may be plugged into an Object::Meta::Plugin::Host instance, or compatible. Calls on the host are diverted to the applicable plugin via an AUTOLOAD routine. Instead of getting the host object as $self, however, the plugin will receive what's known as a context object.
A context object is somewhat like the host, but instead of providing access to all the methods as normal, it gives perceedence to the current plugin's methods. The Object::Meta::Host::Context class provides the super (host is synonymous) method, which return the host object, if access to it is needed. That is, $self->super->method will cause the default method method to be called, instead of the one defined within the plugin.
The vision, in essence, is to have an object's parts distributed across a more flexible mesh than classes and inheritence. Basically these meta objects could be considered a group of objects that look as one from the outside. The tradeoff for this flexibility is that you lose it elsewhere - interfacing. As of now I don't see as solution, besides making the data which plugins toss around themselves objects, to incompatibilities. Since objects, by nature, are extensible and dynamic within while being able to maintain an external functionality which is very backwards comptabile, and even emulate backwards compatibility, they solve this problem. Which boils down to efficiency - don't expect these meta object to be super quick - a lot of overhead will be involved - objects cost more space and time to use than simple structures. The calls between the plugins involve an overhead - trapping AUTOLOAD, creating a context, trapping AUTOLOAD again, and so forth.
That is all I have to say about this module for now. Peek in our CVS repository, or download a snapshot^* if you still care... ;-)

* Not nightly, updated on significant progress.

P.S. If you are a party who sends various messages regarding genital enhancements, miracles/spouses for sale, and so forth, aarnoch@woobling.org might not be interested.