How to handle host-specific feed content

[JaySunSyn]

podcastparser currently parses fields like rss/channel/item/itunes:summary which are specifc to Apple.

Do you accept PRs for parsing fields like rss/channel/item/omny:clipId which are specific to a certain host - in this case OmnyStudio.

[thp]

Is clipId an alternative to the GUID?

[thp]

In general, it should be something that's useful for multiple feeds, so without any additional knowledge/info about how widespread this extension is, I'd say probably not. If it's something that's used by multiple podcasts, and there's a need for podcast clients such as gPodder and others using podcastparser to obtain and process that information.

[JaySunSyn]

clipId is mostly same as GUID but can be different. They are internal IDs of OmnyStudio (which is used by a large amount of bigger enterprise shows) and also respectively used in internal enterprise systems or podcast linking services. Let me know if that's enough info to accept a PR.

[thp]

Doesn’t sound like a good fit for the podcastparser library, as there is no clear benefit to having this ID available in podcast client apps. This is different compared to iTunes extensions.

Jalal Fathi @.***> schrieb am So. 12. Feb. 2023 um 18:03:

clipId is mostly same as GUID but can be different. They are internal IDs of OmnyStudio (which is used by a large amount of bigger enterprise shows) and also respectively used in internal enterprise systems or podcast linking services. Let me know if that's enough info to accept a PR.

— Reply to this email directly, view it on GitHub https://github.com/gpodder/podcastparser/issues/42#issuecomment-1427082065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBASO3Z3FWTSUWYBQ5KT3WXEJXPANCNFSM6AAAAAAUNPIMGE . You are receiving this because you commented.Message ID: @.***>

[pkozlov]

May be we can think about some possibility to make plugins or custom extensions for parser to support custom fields?

[thp]

That sounds like a lot of added complexity for enabling what seems like a feature that one business (OmnyStudio) would use internally, the maintenance burden stays on the open source project‘s side for no apparent benefit to the user base.

There is always the possibility of maintaining that patch downstream in the organzation‘s (OmnyStudio?) internal repos. It’s not like podcastparser is a fast-moving project, it’s mostly stable and mature with only occasional changes.

Pavel Kozlov @.***> schrieb am Di. 14. Feb. 2023 um 15:48:

May be we can think about some possibility to make plugins or custom extensions for parser to support custom fields?

— Reply to this email directly, view it on GitHub https://github.com/gpodder/podcastparser/issues/42#issuecomment-1429866014, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBASOIY3HIHLAFD3EKX3LWXOLNNANCNFSM6AAAAAAUNPIMGE . You are receiving this because you commented.Message ID: @.***>

[pkozlov]

I'm not talking in context about OmnyStudio and this ticket also. Only about idea to make a possibility to customize parsing for some personal purposes. What can make library more universal for some business tasks.

[thp]

(walls of text follow, tl;dr: let‘s NOT add a plugin architecture)

Your idea is appreciated (and a sensible solution for projects that want/need that kind of extensibility), but the design goal of podcastparser is to be simple, fast and turning RSS/Atom feeds into a common data structure that can be consumed by podcast clients (aka apps that subscribe to and download podcasts - gPodder is one obvious example, and the main consumer of the library).

In other words, being „more universal for some business tasks“ is not a design goal of podcastparser.

The „some“ in „some personal purposes“ and „some business tasks“ shows me that there is no clear picture of what it is we are trying to achieve here, and without that, it’s hard to find a solution that solves the problem in a satisfactory way.

Apart from „why should I cater to some vague requirements of some business without getting paid by said business“, there is no way to know what the use case of the business is, and making it super generic makes it hard to design in the first place and hard to later maintain, and you would have to keep the extension API stable, as you might otherwise break out-of-tree extension.

Next counter-argument to shut down: But but.. if one can define an API for extensions? See also: Hyrum‘s Law. Also, it’s a podcast parser, not an operating system. See also: Zawinsky‘s law.

Next counter-argument to shut down: But but.. just keep the API unstable then. If you don’t keep the API stable, no need to do it in the first place, just let them maintain it as a downstream patch against mainline without the „plugin architecture“ scaffolding around it.

If/when a new extension comes along that‘s used more widely (e.g. like with the iTunes extensions) OR makes sense to show to the end user in a podcast app like gPodder (e.g. a travel podcast that has GPS coordinates attached, and the client could show the episodes on a world map) that’s something that would likely be a good fit for podcastparser. And for practical reasons, if gPodder itself needs some feature that’s only used by it, we might add it to podcastparser, as the library is historically a side-product of writing gPodder, and is still very much interwoven in terms of maintainers and main consumer of the library.

As these discussions tend to produce lots of heat and little light, I‘m probably going to close this thread soon.

With that said, don’t feel discouraged to continue bringing up ideas that make sense in the context of the project.

Pavel Kozlov @.***> schrieb am Di. 14. Feb. 2023 um 21:51:

I'm not talking in context about OmnyStudio and this ticket also. Only about idea to make a possibility to customize parsing for some personal purposes. What can make library more universal for some business tasks.

— Reply to this email directly, view it on GitHub https://github.com/gpodder/podcastparser/issues/42#issuecomment-1430358203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABBASKLMVVQ3JZ5MT5RUP3WXPV6LANCNFSM6AAAAAAUNPIMGE . You are receiving this because you commented.Message ID: @.***>

[pkozlov]

OK, got you. Only one question I have now. You are positioning this library as a gPodder side-product and only gPodder needs will be fit in product map?

Because I'm using now this library for my projects (PC.ST as example), and looks like if I will have some specific needs it is a better way to go with private solution for parsing...

[thp]

OK, got you. Only one question I have now. You are positioning this library as a gPodder side-product and only gPodder needs will be fit in product map?

There is no "product map", and there is no "product" as such. At least I'm not getting paid :)

Because I'm using now this library for my projects (PC.ST as example), and looks like if I will have some specific needs it is a better way to go with private solution for parsing...

What I'm saying is that the original question by @JaySunSyn of Podkite (a for-profit company without even a free tier update: with a free tier, as mentioned below) was asking about adding support for a OmnyStudio (which doesn't even show its pricing, and only has "get a quote") specific feature that are not useful outside of those contexts would be a good fit for merging upstream into podcastparser.

And my answer there was no, why should we maintain a feature we can't use and can't test/validate. If you are running a for-profit company and need features that only apply to your specific business case, you should have the money to maintain that downstream yourself or pay someone to do it - and this is true for features such as the OmnyStudio clipId.

pc.st seems very different from the above use case, and seems more like a podcast client in the cloud that doesn't cost me anything. I'm sure if there's any features you need for pc.st we would be happy to merge them (as a feature in mainline, no need for plugins and stuff), and it's probably something gPodder and other users of the library (including Podkite) have use for as well.

If there are PRs that benefit clients like gPodder and pc.st in addition to e.g. Podkite, PRs are gladly accepted, but I just don't see this is the case for the OmnyStudio clipId feature in question.

In fact, #37 (iTunes categories) was exactly such a feature that we gladly merged (thanks @JaySunSyn!) because it's something that's of general use, even though we don't use it in gPodder (yet?), it'd be something that can be used by gPodder and pc.st too for user-facing content.

For features such as OmnyStudio clipId, you don't even need to maintain a patch downstream, just add to podcastparser.MAPPING and podcastparser.Namespace.NAMESPACES after importing and before parsing and you can add custom handlers that don't need to live in upstream. Note that these are kind of implementation details, so might break with future releases, although it's very unlikely practically speaking, and you anyway check your dependencies for changes when upgrading packages, right? :)

[thp]

So to answer the specific question from the original posting:

just add to podcastparser.MAPPING and podcastparser.Namespace.NAMESPACES after importing and before parsing and you can add custom handlers

[JaySunSyn]

Just to be precise, Podkite has a free-forever-tier (most users are on that one) and happily also sponsored https://github.com/gpodder/podcastparser/pull/33 ;)

[thp]

Just to be precise, Podkite has a free-forever-tier (most users are on that one) and happily also sponsored #33 ;)

Didn't know about the free tier. Amended my answer above for the record. In any case, overriding MAPPING and NAMESPACES after import should do the trick for omny:clipId, right?

[JaySunSyn]

Yep, that should do it, thanks :)