Merge with or defer to iTunes module?

I'll take a look into this... on the todo list.

It's a bit a shame to have these two modules because there's quite some duplication. I'm not ranting at all, the 2 modules have different stories and have evolved to what they are now. But maybe a merge could be done ?

The way I see it, they both have their own advantages :
- FFPC does a good job at guessing the itunes tags from the files metadata
- itunes does a good job by allowing the itunes tags to be customized for each node individually and for the view globally

Best regards,
Guix

Not when I was writing the comment, but you are quick ;)
Indeed duration is now here and hopefully others are to come.
However I have a concern with relying on files metadata only (and that's why I prefer the itunes approach to FFPC's) : how easy is it to insert the metadata in the files... For my users I guess downloading a full blown editor for each file type (.flv, .mp4, .mp3, ...) would be asking too much. Or maybe there's an OS cross-platform metadata editor for the most common media file types ?

Here's my vote for either merging FileField Podcaster with iTunes or deprecating in favor of it. iTunes has come a long way even since this issue was created. FFPC, on the other hand, seems to have stagnated. There hasn't been a new release since 2008, and the issue queue is about as dead. And even were that not the case, there's a lot of duplication of functionality, of which iTunes' implementation is fuller. I hope the maintainers of this modules will accept @drewish's offer of cooperation since he seems both committed and active.

I'm ok with the concept of the merge, but there's some things I'm really not liking about iTunes module. The biggest is that it's conceptually misleading. What if I want an audio/video feed but don't want to list it in the iTunes Music Store? The iTunes module assumes that everyone wants to use iTunes, which they don't.

Now, that doesn't mean it won't work other places, but I think the concept and name of the module are overreaching and confusing.

The reason I love FFPC is that it's simple. It does one small job: allow to you to create a media feed from a filefield. Personally, I don't want a module to attempt to do everything for me...I want it to do simple things so I can customize the rest. iTunes module has similar problems in concept to Audio module (which are the same reasons I created FFPC module to move away from audio.module): It tries to be an all in one solution (to it's credit, at least it's not creating a content type). I see Drupal as most powerful when it's modular in approach...I'm not a big fan of any module that tries to give me a complete solution, and I feel that iTunes module borders on this.

I'd be more into this idea if the iTunes module was just a tagging module (specifically for use with iTunes) of some kind and didn't output a feed (although I'm not sure how that would work) I feel that FFPCs strength is it's simplicity.

The reason there's been no updates and few issues is that it "just works". It does a simple job and, I think, does it well. More discussion would be beneficial but for right now, I see these two modules as having slightly different goals, approaches, and purposes.

@Rob_Feature: I'm in complete agreement with you on the importance of modularity and application-agnostic design. I also don't care for the name "iTunes" for a general solution. My preference would be a module called, say, "Podcast" that just gave options for specific applications like listing in the iTunes Music Store. I personally like the general approach of FFPC better because it's more flexible and makes fewer assumptions, but it has some distinct shortcomings as to my needs, specifically the inability to add iTunes-specific tags. Here are some more specific thoughts on each:

iTunes

The Good

• The main, obvious strength of iTunes module is its handling of iTunes-specific tags at the channel level. There's simply no way to get this with FFPC—I don't believe there's even a template to override mannually.
• The module maintainer seems active and committed. I even see him in the FFPC issue queue sometimes.

The Bad

• The application is too specific. This affects, first of all, expectations, as @Rob_Feature says. It also affects findability. "iTunes" probably isn't the name someone will go looking for when seeking a podcast solution, especially if they don't care about the iTunes Music Store. (I suppose it's worth noting that the module does give the option to keep the feed from being included in the iTunes Music Store, although that's not the point.)
• It's not flexible enough on with individual feed items. There's a single, global interface for defining what field is used for attachments per content type. I don't really like the addition of another configuration menu item when unnecessary, but more importantly, that's too limiting. What if I want to do two separate feeds from a single content type? For example, suppose I have a "media" content type to which I want to attach both audio and video to create a podcast and a separate vodcast? From what I can tell, you can't do that.

FileField Podcaster

The Good

• Its generic, application-agnostic approach is far to be preferred. Applications like that mentioned above, a podcast and a separate vodcast from the same content type, are its bread and butter. By necessary consequence, its settings are right in Views, where they should be. I feel like it's done "the right way"—much more consistent the Drupal philosophy, I think.
• The fact that it's better documented and has a great Mustardseed Media video tutorial (and endorsement) is not to be overlooked. That means a lot.

The Bad

• I think the name FileField Podcaster could even better be just "Podcast". I suppose an argument could be made either way, but I wonder if it doesn't confuse some people.
• There's just plain no way to add iTunes-specific tags (unless I'm overlooking it). For this single reason I had to abandon my beloved FFPC in favor of iTunes yesterday for a client who was taking their podcast to the iTunes Music Store. Alas!
• Issues in the queue just don't get much love.

In short, iTunes is great for the feed channel (if you're taking it to the iTunes Music Store) and FFPC is best for the feed items. I actually tried to use them together yesterday, iTunes for the feed style and FFPC for the row style, but got an error.

Common Weaknesses

There are a couple of things that neither module does that I think are important:

1. Fill tags from field values. This speaks again to flexibility. Sometimes you want neither to manually fill all your details (as iTunes does) nor pull them all from the node and its fields (as FFPC does). For example, you may want to have the episode date reflect the value of a a date field instead of the published time of the node, as requested of FFPC here #430850: Map pubDate, summary, author elements, etc. to custom fields. Or perhaps you want the item summary to come from somewhere other than the node body, as requested of iTunes here #481076: Add choices for the item <itunes:summary> source. (Similar is #773308: Ability to fill iTunes feed settings from cck fields?.)
2. Add arbitrary tags. Suppose someone has a need for a tag that is neither native RSS nor iTunes-specific. If this seems excessive...
3. Provide all possible Views templates. FFPC is missing a row style template. (See #520122: Add row style template (tpl.php).) iTunes is missing a style output template. For the greatest flexibility, all these pieces need to be themeable.

I think both modules have great strengths and notable weaknesses, and I don't think they're mutually exclusive. As implied before, they seem like they could almost plug into one another! But most of all I think there's a lot of duplication of effort (we even seem to be duplicating this conversation! #537968: Rewrite for better Views integration / merge with FFPC ?) and division of user base. I'd sure like to see a merge. And that's my two cents. :)

The iTunes module is different than ffpc. I recently looked into using it.

For example, a single node has an mp3 and an aac file attached it. With ffpc I can create a feed for the mp3 and a separate feed for the aac. With iTunes any feed with have both of them included. A difference is where the files are added as enclosures. With ffpc they are added in the view. With iTunes they are added in hook_nodeapi with the rss op.

This is a fundamental difference.

If the two modules merge there needs to be a way to handle the multiple use cases both these modules currently handle.

That being said, I am all for merging the two modules. Even deprecating this module if it is no longer needed.

What we need, frankly, is a migration path to Drupal 7 that doesn't break fully compatible iTunes channel feeds... so we still have channel artwork, and an author, and a copyright field, etc, and which allows sites with podcasts to move to Drupal 7. Do the views_rss and views_rss_itunes modules enable that? Probably. Would I be migrating to those modules if ffpc and iTunes had merged back in 2010 and been actively developed as proposed? Probably not. :)