Drupal Association members fund grants that make connections all over the world.
Outlined here is a plan to migrate the playlist module's functionality into audio module contrib.
1) Playlist Relationship API duplicates and clutters other node relation efforts.
The current playlist module consists of playlist.module and audio_playlist.module. Playlist.module was supposed to be a relationship API for media files. However we must realize that there are many existing relationship APIs in drupal and they all do a similar thing. A universal relationship API is a better solution than many modules doing the same thing. I don't feel it's worth developing out yet another relationship API with such limited scope.
The Playlist API is not being utilized by any other modules (that I know of). This module has pretty much only ever been used for audio playlists. I think it's safe to cut this API out to simplify things.
2) Current functionality is not modular enough.
When this module was first written, it was conceived to do a few things - create audio XML feeds, store playlist metadata, and provide an interface for managing lists of audio files. However, all of this functionality was mostly bundled into audio_playlist.module which was meant to deal only with audio playlists. Trying to do all of this in one module was kind of clunky since it had to deal with data storage, interface design, and feed generation all at once. It also meant the code was all interweaved together, making it hard to maintain and inflexible if you wanted to mix and match functionality.
The Way Forward
Nobody can predict the changes that will happen in Drupal, but I think it's always a good idea to try and at least plan for the future. I know that more modularity is always a better design choice, as it reduces the amount of code that needs to be maintained, and conceptually breaks down a large problem into smaller pieces. I also know that personally I have much less time to work on this than I did two years ago. I would like to think that modularizing things will make it easier for me and others to handle the work in the future.
Conceptually I'd like to break functionality up as follows:
Update the existing audio_attach contrib module to allow a user to attach multiple audio files to any node type and re-order them. This is the first thing that needs to get done.
This would provide XSPF, M3U, and PLS audio feeds for a list of audio files, either created by audio_attach.module or by views.
Audio_itunes.module *COMPLETE Check here*
Many people just want the ability to create and control iTunes compatible podcasts. To do this you need a way to store the podcast metadata for the feed, which this module would handle. This module would act upon a list of audio files generated by views.
This adds an "Add to playlist" link to every audio node so that people can add any audio file to a list of attached files.
Even Further into the Future
With such modularity, it is easier now to create an audio_album.module which would let you create specialized album node types where you could attach audio files. Or you could create different types of playlists with different access permissions.
Please post any comments or questions here. An upgrade path to this new method is also something we'll need to consider as we move forward.
I appreciate everyone's patience as this module gets sorted out.
Open source development ALWAYS tests your patience ;)