Phase 6 - The Plan

[daveajones]

Time to start formalizing a list of what we want to be in phase 6. I think the following are straightforward and make sense:

• remoteItem Proposal - <podcast:remoteItem> tag #481 (done)
• list mediums Proposal: List mediums #480 (done)
• acceptsGuests Proposal - <podcast:acceptsGuests> #474
• podroll Proposal: New element <podcast:podroll> #451 (done)
• updateFrequency Proposal: <podcast:updateFrequency> tag #515 (done)
• podping Proposal: <podcast:podping> tag #517 (done)
• valueTimeSplit Proposal: <podcast:valueTimeSplit> tag #512 (done)

Please give input here on what you think is a realistic target set of tags and enhancements.

[geeknews]

The only real question I had was about some of the examples feeds for Remote-Item where creating standalone feeds with Remote-Item only

1. What happens with those feeds, aka where do they get used
2. Will they be referenced in the master feed of the show

I think things are clear for remote-item that appear in the channel of a feed. But I question what the standalone feeds will be used for and how they will be referenced back to the creator

[picard102]

Person Tags accepting more than one role would be a nice update.

[daveajones]

You mentioned in a previous comment that you'd like to have id's instead of role slugs. Do you have any ideas around that? The discussion was moved here: #498

[picard102]

Just that having something like a "role-code" as part of the taxonomy would make sense to me, instead of using the "role" which seems more human facing. I can go either way though.

[theDanielJLewis]

What would it take for enhanced notes/chapters (#469) and replaces (#449) to be considered for phase 6?

[samsethi]

Notes, Chapters and Transcripts should be one doc just as you get a word doc with titles and txt. You can collapse down a document to see the outline and expand it to read the paragraph txt with links.

[theDanielJLewis]

I think that's been discussed before, but transcripts come in multiple formats, while chapters are only JSON.

Plus, I, for one, love being able to drop an SRT file straight in without having to merge or convert.

Also, I think the data content would be radically different. A transcript might refer to an external site, but the notes would link to it. A transcript might not have section headings, but notes would.

This is why I think chapters and notes go together much better than anything else. And it's likely the notes would duplicate the chapters if they were separated.

[keunes]

I would suggest to continue the discussion about combining data into one file in the existing discussion #467.

And here focus on DJL's question (at least replaces tag as it wouldn't be superseded by merged episode metadata).

[keunes]

Side note: issue #400 is now discussion #469, in case folks want to reply to that.

[theDanielJLewis]

I think "podroll" should be pushed back to phase 7 to give us more time to make it a better feature, like I'm suggesting in #508. If we do it well, we can make something far more future-friendly, extensible, exciting, and of greater value to audiences, podcasters, and developers.

[picard102]

Unless you're hand writing your RSS feed, it would be no more complicated to implement than many of the other tags.

[geeknews]

Everyone wants the kitchen sink, but they need to start thinking like an average podcaster and the workload they have to do. If it takes more than 5-10 minutes to implement, they will never implement it. If you start imposing all kinds of criteria, the average podcaster will say what the heck is this and move on. I know folks want GUID included in the spec. Good luck explaining that to a podcaster.

[ericpp]

Some type of recommendation system (podroll, recommend, whatever) would be useful as we venture into music podcasts. As a user, I want to listen to a constant feed of music rather than having to hunt down albums I might like. Having some way for artists to recommend other artists or albums would allow apps to assemble a constant feed of music based on artist recommendations.

[picard102]

The average podcaster doesn't implement anything ideally. They fill in a form when publishing a new episode. Hosting platforms would do the implementation.

[theDanielJLewis]

I'm not asking for the kitchen sink or even a hammer that can also drive in screws. I'm asking for a simple hammer that can hammer galvanized nails, stainless steel nails, and plastic nails. Same tool, the same tasks, only slightly different purposes.

[daveajones]

Added #515 from @nathangathright

[agates]

Can we have <podcast:podping>? This will be extremely useful for notification support for standalone apps and some other future podping implementations.

Even if it's just <podcast:podping usesPodping="true|false"/>

EDIT: Relevant issue #258

[jamescridland]

Question: is podping inextricably linked to the Podcast Index? If it is, then surely this is an automatic field that can be populated by the index, rather than a manual thing having to be put into the RSS feed.

Further: what happens if the podcaster says it's podping enabled, but doesn't actually send any podpings? Better, perhaps, for the Podcast Index to check whether they've had a podping update in the last 90 days, and check/uncheck that value automatically.

[daveajones]

Podping runs independently of PI. There is no dependency between the two.

[jamescridland]

@daveajones Thanks. What are your thoughts about the PI maintaining a "uses podping" flag? Seems more reliable than something in an RSS feed.

[daveajones]

Added #517 from @brianoflondon and @agates

[tomrossi7]

I know folks want GUID included in the spec. Good luck explaining that to a podcaster.

@geeknews why are you explaining it to the podcaster? Unless he is creating his own RSS feed, this complexity should be totally hidden.

[geeknews]

Sure, we would implement lookups but with so few shows actually having a GUID at this point, whats the fallback still far simpler for them to enter a show name, show host landing page, and be done with it.

[theDanielJLewis]

"The GUID is a globally unique way to identify your podcast, and it can go with your podcast across apps, platforms, hosting providers, tools, and even migrated RSS feeds."

[jamescridland]

Hey, @geeknews - at no stage does the podcaster need to be aware of the GUID. Ever.

Every show has a GUID: if it's not explicit in the RSS feed, it's been set in the Podcast Index.

Write a lookup that queries the Podcast Index. Ask the podcaster "what show do you want to link to?" and give them a box to type the show name in. Behind the scenes, you add the GUID to the podroll. Easy and simple.

Show names change; RSS feeds change; but the GUID never changes.

[geeknews]

Since when did the index assign a GUID for every show we did not pull guids from the index when we enabled it. This is news to me. FWIW, it will not be a simple search due to the high number of shows with the same name or very similar names. It will have to be a search with multiple results to pick from which complicates the integration.

Again much much easier to allow the podcaster to write the name of the show and link to the show's website. I guess no one has ever had a blogroll.

[daveajones]

You don't have to pull GUID's from the index. If the feed has one, we use it. Feed is the source of truth for us always. We just went ahead and generated them all according to the GUID spec in the namespace.

[daveajones]

Ok, phase 6 is fully written up in the XMLNS now. Cleaning up the README.