Open mpgirro opened 3 years ago
What if the Rfc5005
companion object had a helper method one could pass a List<AtomLink>
to, and that would return a wrapper object with those helper methods? It's not the most elegant UX, but it keeps our code organisation in place and keeps Atom stuff separated. That way, if users want to check the RFC5005 links, they can manually pass in the Atom links list (or perhaps the whole Podcast
, doesn't really matter) and get the information they need, and those who don't don't get cross-polluted APIs.
I think this is a good idea.
Regarding the name, the namespace prefix is usually fh:
and I've found that the initial draft of the spec referred to "feed history", so maybe we can just use that.
It is a less horrendous name than rfc5005, yes eheh
Open question for me right now is if the atom:link
elements with respective rel
attribute values may only be interpreted in terms of RFC 5005 if the namespace is declared in the feed. Lasted feed analysis results show that 1,2% of all feeds declare the namespace, but not a single feed uses an element.
Will need to check the spec for this.
RFC 5005 defines paging and archiving for feeds. While I've never seen an archived feeds out in the wild, paging information is quite common (e.g., default for Podlove Publisher feeds). The namespace itself is pretty small – only two unary elements are defined. Most information from this standard is encoded in
atom:link
elements, with specific values for therel
attribute.The challenge here will be the API design. We'll have to add a dedicated property to
Podcast
for the unary elementsfh:complete
andfh:archive
of course. But from this property – let's call itrfc5005
for now (don't have a better idea anyway) – we can't access theatom
property with the link information, e.g. to provide getters for retrieving links with specificrel
values. We could add those getters directly to thePodcast
, but this wouldn't be consistent.