You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To define 3rd party metadata: any data not created by a podcast owner (through rss feed) or by podcastindex itself (craw dates, update dates) that has information on the main data, namely the podcast feed and it's episodes.
@daveajones I'm sure you have had ideas and working on how to handle incoming metadata like:
reviews and ratings
info from source/media crawlers, timing bitrate
secure thumbnail/image mirrors
possible dupe feeds
donate links
etc...
And perhaps you're already heading in a different direction.
But what were your thoughts about just an extra key/value table with namespaces? So a unique index could be namespace:feedId:key. You could by request connect API keys to a (single) namespace to give them write access. If any party needs access to multiple namespaces, they can use multiple API keys.
I'm not too sure though how to present the data in the API in a efficient way. It seems a good idea not to show any of this data by default, but only if a connecting service is aware that a certain namespace exists.
For popular searches and request on the metadata I'm sure @daveajones will whip up custom endpoints in no time.
My main concert, could the database handle it this way? I think it could provide a lot of flexibility.
The text was updated successfully, but these errors were encountered:
I am also interested in 3rd party data that connects to a feed. However, I assumed that would be something you or I or they would host themselves. You'd download/get access to the main podcast newsfeed so that you'd have the correct podcastID to point to, but you would host the "child" database yourself. Reviews, Ratings, etc.
While I like the idea of your dynamic namespace idea, wouldn't Dave ALSO have to somehow dynamically host this metadata you're talking about? Which doesn't seem possible.
Perhaps I'm reading your idea wrong -- would love to hear more.
Update: Looks like Episode #6 talks about the namespaces that ARE being added.
To define 3rd party metadata: any data not created by a podcast owner (through rss feed) or by podcastindex itself (craw dates, update dates) that has information on the main data, namely the podcast feed and it's episodes.
@daveajones I'm sure you have had ideas and working on how to handle incoming metadata like:
etc...
And perhaps you're already heading in a different direction.
But what were your thoughts about just an extra key/value table with namespaces? So a unique index could be namespace:feedId:key. You could by request connect API keys to a (single) namespace to give them write access. If any party needs access to multiple namespaces, they can use multiple API keys.
I'm not too sure though how to present the data in the API in a efficient way. It seems a good idea not to show any of this data by default, but only if a connecting service is aware that a certain namespace exists.
For popular searches and request on the metadata I'm sure @daveajones will whip up custom endpoints in no time.
My main concert, could the database handle it this way? I think it could provide a lot of flexibility.
The text was updated successfully, but these errors were encountered: