Pushing alternateEnclosure over the finish line

[daveajones]

Now that we have a full, detailed proposal, what is need to get this one done?

Links:

• Spec doc
• Issue discussion
• Live Example Feed

Feedback here is appreciated. I don't see this as something hosts would adopt immediately. I see it as a "need to have" in order to allow platforms like PeerTube and the like to deliver content to RSS podcasting easier. With that in mind, I think the current spec works well. I'd just be interested in what could potentially be showstoppers for implementation by other platforms.

[daveajones]

@agates Can you help me understand the usage differences between rel and default attributes? Maybe it's just a wording thing in the spec, but I'm not fully grasping what they mean.

[agates]

@agates Can you help me understand the usage differences between rel and default attributes? Maybe it's just a wording thing in the spec, but I'm not fully grasping what they mean.

default -- defines whether or not the file defined by alternateEnclosure is the same file as defined in enclosure. This is primarily to define more than one way of obtaining this file.

So if you have the same audio .mp3 file defined in the enclosure and wish to provide the same and/or alternative source for the given .mp3 file, you would set default to true.

If you had the same audio encoded as a different way, say .aac or .opus, you would set default to false.

rel -- entirely different media from the enclosure. This will never be set to default because it will never be the same file. I am not hard set on this attribute however some have expressed interest in it. It's a way to link two types of media without wholly defining a new item, like a commentary track, bloopers, "making of", or something. If that's too confusing, I have no issue with removing it.

[daveajones]

rel seems iffy to me too. It seems like one of those attributes that look good on paper but never get used in practice.

You know I'm not one to get hung up on naming, but default may not be the best choice. I'm not sure it conveys what it does. But, I can't think of anything better either.

[agates]

Maybe default could just be sameAsEnclosure?

rel would be pretty easy to add if someone comes along asking for the feature, it's one of those "podcasting hasn't been used for this yet" kind of things. If I recall correctly I only kept it because it was in the original proposal.

[daveajones]

I'll make those changes for now.

[theDanielJLewis]

What would you think about changing the tag to <podcast:altEnclosure>? It's 6 fewer characters and it might also eliminate potential mistakes writing "alternative" instead of "alternate."

Of course, I'd like to have #239 considered for this, too. But that can probably be an added attribute later.

[eteubert]

It's 6 fewer characters

Readability is more important a few saved bytes. You might argue that there are many enclosures and it multiplies, however with gzip even that becomes irrelevant.

[theDanielJLewis]

Yes, readability is more important, which seems to also support the idea of preventing confusion between "alternate" and "alternative."

[agates]

Yes, readability is more important, which seems to also support the idea of preventing confusion between "alternate" and "alternative."

This is completely subjective, depending on the person, native spoken language, culture, preferences, etc. alternate is specific enough, alt could mean many other things. And then you get to the question about calling the tag altogether something without enclosure in the name, and we've been down that road already.

[mitchdowney]

Hey @daveajones, @RyanHirsch is trying to add liveItem + alternateEnclosure support to podcast-partytime, but the spec says "length" is required for alternateEnclosures, but liveItems won't have a length/duration. Should the alternateEnclosure spec be updated?

I guess technically .m3u8 files have a length/file size, but that doesn't seem useful for a livestream.

[daveajones]

Ooh. Yeah let me look at that.