This continues a discussion started via email on the future of the media module.
- The hook_file is still a good idea [1]. No matter how many X-node modules we add (image, mp3, Word document, etc.), there will always be two points of entry for a file because of the upload module, so finding a way to bring upload.module into the fold is a great beginning. If we could use the hook_file to create image nodes when people attach images to posts I bet Dries would commit the patch finally.
- The approach the media module takes to storing metadata sucks because it tries to be everything to everyone.
- ID3 is really great and there should be an ID3 API based on the hook_file that does nothing other than open up administration options for metadata collection (kindof like the media module does now, but better). It should not try to store the information.
- There should be media handler node types for just about anything that anyone wants to use; mp3, ogg, mpeg4, avi, flv etc. The reason we need these node types is because we can then leverage the mime_registry.module to create dedicated nodes from the files that come in via upload.module, mail attachments or directory scans. Each of these dedicated modules would use the ID3 API to get metadata and would be individually responsible for storing metadata, as well as for presenting the media (outputing the right tags to make it play or stream).
I don't necessisarily think that these node types need to be the main point of entry for files. I fully support the idea of letting them live in the background as shadow nodes created as the result of attaching files to blogs or pages. It just makes so much sense to be able to do nodey things to them (taxonomy, nodeapi). For example, when I attach an mp3 to my blog, I don't expect that it shows up on my blog as a Flash media player with all the ID3 information. But I would expect that if I fire up the rewritten img_assist module (now named file_assist or media_assist), that I could inline that mp3 in the current or any subsequent blog post because an mp3 node was created in the background. This will also aid searching for media.
- Playlist module. It's clear that managing playlists is fun and cool, and we need a good way to handle them. The media module is almost to a good starting point; the update that I began and abandoned (in my sandbox) made some progress because it disabused people of the notion that they created a playlist node in order to upload files, which was the first big misconception (and a vote for Boris's conviction that people expect dedicated node types for individual file uploads).
The playlist module is also the key to making Drupal a real podcasting platform as a playlist RSS is much better than just making an enclosure out of the first file attached to a node (useful but weak).
Looking forward to the future of Drupal media!
Comments
hey robert
I'm working on a playlist module that can create and order nodes of any type. Eventually I want to merge it with the taxonomy table but right now taxonomy is limited so I have to use my own playlist table. I really think a playlist is nothing more than taxonomy term with order for nodes and an owner. I thought about making it a node, but a playlist isn't really a new piece of content, it is a collection of existing content. Each person can also make multiple playlists, and each playlist generates an RSS feed (and hopefully XSPF and others).
What do you think?
I will post the code soon, or I can send you the rough copy.
Farsheed
node_relationship
Farsheed -- we talked about this while thinking about lots of things, including venues for events.
Playlists can be implemented as node to node relations. Adrian is in the process of coding something up for this.
So, you would create a playlist node, then you could make N other nodes related to it. The node_relationship could have a theme view that is tabular.
Colin will likely help re-write it to work like this.
Hey Boris
Awesome. Colin mentioned this to me today. Have you read up on node_relativity? I really think this does a similar thing, but maybe that's just me. It stores parent and child relationships, as well as related node items. For the ultimate relationship system, a 2-D or 3-D node map seems like the answer. Javanaut, where you at???
There is still some problems though, primarily with what exactly a playlist is. Adrian made a good point that it is simply a taxonomy term that stores node relationships. I agree with this view.
It sounds like the ultimate solution would be to use Adrian's node relationships with taxonomy. However I think one big issue is to associate taxonomy terms to user IDs, to allow ownership over taxonomies (and thus playlists). I submitted an issue to the queue today.
The node relationship is a very powerful idea, allowing people to group nodes together to create a sequence of node such as events (a tour schedule for example), or media (playlists), or just about anything. I look forward to this code, and will try to help out in any way I can.
Farsheed
Playlist != Playlist
Remember that in the media module, a playlist is a list of urls that gets sent to a media player which then plays the files in that order. This is quite different than a playlist that Drupal understands (an ordered collection of nodes and a way to browse betwee them, as I understand it from your description)
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Right
I agree, a playlist means different things depending on context. Drupal manages a collection of nodes in an order which could then create a playlist feed, or multiple playlist feeds. So Drupal could maintain a collection of nodes and then you could have RSS, M3U, and XSPF playlist feed generated from the ordered list of nodes. You could also plugin more playlist format types into the node playlists...or did I not understand you? I think such a modular system would allow for multiple playlist file format support.
Exactly
You get a node display, and from that we generate whatever we need.
Thanks Robert
Great ideas!
I’ve been working on an audio module (where each audio file maps to a single audio node), and I’ve just checked some code into CVS. The module reads and writes ID3 information, and provides a default flash player to play back content.
I certainly see your point about media nodes not being the main point of entry for files. That is not how I built this module, but if/when hook_file() comes into existence it should be fairly straight forward to modify this module to have audio nodes created in response to file upload events. Really though, I see a need for both types (A dedicated standalone audio node type, and an ability for an audio node to be created when a audio file is uploaded to a blog, for example).
Excited
Colin,
great work on your module, by the way, I'm thrilled to see the direction Bryght is moving in with this. Your module fits nicely into the scheme above, especially if hook_file comes through. Since the patch is available, maybe you could create a patch for the audio module that uses the new hook and there would be 2 modules (twice the incentive) that use it. Then if we could get image module involved as well I believe it would start to be really useful (the hook).
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
my two cents :)
the problem as i see it is that everyone wants multimedia files and embedded (id3 type) information, but everyone wants a different presentation.
the problem that birthed the MVC design pattern.
i've reviewed the existing modules and have decided to write my own, just as a lot of others have. i too will be using the getid3 library. i want the same data each of you wants, but i want to present it aribtrarily. i don't want to limit the scope of this data to a single node that assumes how the user wants to present it. i want to be able to add this info pretty much wherever i want, however i want. add 'songs played over last 10 minutes' to header. add 'most popular tracks' to sidebar. create different pages for different purposes - but all of these should use the same data source and access method.
so i'm creating (for myself) a media.inc library that will wrap getid3 into a drupal digestible interface. i'm going to create a new database table that *augments* (doesn't replace) the existing files table.
for now, i'm going to create a custom node module that will present a "page node" suitable to my needs.
later i should be able to use hooks to create new features to other parts of drupal if needed.
i think the ultimate answer, something suitable for inclusion in the core, is a separation of files and embedded information from presentation.
there's no doubt here that there's a lot of interest in adding multimedia features to drupal. the question is, will there by a unified effort to do so or will everyone just branch off and do their own thing (as i'm about to do)?
--
Devbee - http://devbee.net/
getID3 API
If you're working on something that can function as a general getID3 API, where any module can use its functions to extract or retrieve getID3 information and centralizes getID3 administration, I think you'll find a lot of unified support (Colin, confirm?) That directly hits one of the points I made above. Great initiative, thanks!
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
i don't want to limit the
Nothing you mentioned prevents you from extracting this data directly from the audio module. In fact, songs played and most popular tracks are two things that will most assuredly be part of the audio module (likely as a function displayed in a block, which can of course be re-used anywhere in a theme), and the data structures are already in place to track that info.
Since Colin *just* committed the module, it might be worth looking into. Unless you're going to be tracking information that's not audio?
bad examples
maybe my examples were bad, but my point is the same.
having everyone interested in tag info reading in the tags on each request is an expensive proposition.
the "right thing" to do is to store that information in a database. read the media file once, store the info for all to share.
then any module that wanted to could make calls such as get_artist_name() get_track_length() or whatever the heck else, and do whatever, however, whenever it wanted.
modules are meant to provide a specific type of feature to drupal. the include files are meant to make a general type of functionality available to the modules (user, node, database, session, etc...).
i think multimedia is a very broad thing, requiring a library (ie inc file).
imagine if instead of multimedia functionality, we were talking about say database functionality. if every module needed to create it's own method of interacting with the DB, Drupal would be an utter disaster.
while multimedia certainly is not of the scope of database access in the drupal context, it's certainly more of a general functionality (such as database access) than a specialized feature that falls into a nice tight package (such as the aggregation module).
i hope that makes sense :)
i'm going to be implementing this on a very small scale (only interested in a few id3 elements right now) for my own app.
i'll post what i have as soon as it works. maybe those of us interested could work together on the library and then work independently on our own modules that rely on that library :)
harry
--
Devbee - http://devbee.net/
Good plan.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Good ideas
You have many good ideas here, but I just wanted to clarify a bit. You say:
This is exactly what the audio module does. It has an audio meta-info table that augments the file table. When an audio file is uploaded, ID3 information is read from the file and stored in the audio meta-info table. At the theme level, it is fairly easy to display whatever meta-information (in whatever format) you would like.
Other modules can query this meta-information by just looking in the database directly, or calling functions in the audio module, such as get_latest_audio($n) which would return the n latest audio files. Another example might be a playlist module that uses a function in the audio module to retrieve and display previously collected ID3 information.
You also point out that:
I could not agree more on this and I love your analogy. I guess I had thought that the audio module might be analogous to the database module in that it provided a common interface to all things audio. I wanted it to be small and singular in purpose just for these very reasons.
One of your suggestions of pulling out the getID3 parts into a common library is a really great idea though. I would love to remove this stuff from the audio module and just have some nice drupal-ish functions to call. But I think that the handling of various media types, and the storing of the gathered ID3 information should be left to dedicated media node types. (A video module to handle video content, an audio node to handle audio content, etc...), as opposed to a general, one size fits all library. I do love the idea of some common functionality being pulled out of these various modules though.
Looking forward to seeing this stuff happen!