Hi Thomas,
the main points of the gpodder.net API spec we try to address are:
* *No queue synchronization* - a feature wanted by a lot of people,
since many podcast clients have some kind of queue.
* *Only media URL and feed URL for element identification* - this lead
to duplicate entries in podcast apps since media URLs can change for
a given episode and even podcast feed URLs can change, e.g. with a
301 redirect.
* *Episode Actions produce huge amounts of data* - to store every
interaction with an episode generates useful data, but is not very
efficient. (I heard that the episode actions are the main reason for
gpodder.net being overloaded and slow sometimes)
* *Devices are not intuitive* - I heard that many users don't
understand how to use the devices functionality.
* *API spec is pretty complex* - implementing endpoints like
Directory, Suggestions, Podcast Lists doesn't seem to be necessary
for simple API spec implementations focused on synchronization, but
I couldn't find endpoints informing about sync server capabilities.
A simple reference implementation for testing purposes is a good idea.
I'm planning to implement a sync server as a Nextcloud app, just like
Nextcloud Gpodder. Converting the Nextcloud app to a simple, standalone
php reference implementation is pretty straightforward afterwards.
We thought that a single meeting might be more productive to share
knowledge and plan necessary endpoints and scopes of the spec. Since
currently four to five different podcast client maintainers are
involved, we thought that this would be a good idea. If we can't find a
date that suits everyone with the poll, we might have to switch to
asynchronous discussions.
We are discussing the specification in a GitHub discussion here:
https://github.com/thrillfall/nextcloud-gpodder/discussions/91
If the maintainers of gpodder.net are interested, we could also work
together on gpodder.net 2/3 to improve it. But since the API hasn't
changed for 5+ years, I figured there probably isn't much interest in that.
Greetings
Jonathan
On 19.09.22 08:26, Thomas Perl (thp) wrote:
Hi Jonathan,
Do you have a list of “problems we have with the gpodder.net <http://gpodder.net> API”?
In general, having a “reference implementation” of the API that can be ran standalone locally and using files (e.g. SQLite) as backend might be good to test different implementations. This is something I could use right now for the minidb1-to-minidb2 migration in gPodder (where it’s used for gpodder.net <http://gpodder.net> sync).
Why have a meeting and not discuss on a mailing list thread or github issues thread? Doing those things asychrononously has the advantage of not being restricted to whoever-happens-to-have-time-for-the-meeting. It’s not like there’s a deadline or anything, so getting things started right away and discussed right away might be easier.
In any case, if you list the problems the current API design (not implementation, that’s a separate thing) has, please put them somewhere and we can discuss them.
Thanks,
Thomas
On 17.09.2022, at 20:04, Jonathan Flueren <jonathan@xxxxxxxxxx> wrote:
Hello gpodder team,
together with the team behind AntennaPod <https://antennapod.org/>, I am currently working on an open podcast client synchronization API.
Our goal is to create a synchronization API specification that fixes some problems we have with the gpodder.net <http://gpodder.net> API that is currently used by many podcast clients.
Until the project is mature enough to get its own repository, we are discussing the new specification in the repository of the minimal Nextcloud gpodder.net <https://github.com/thrillfall/nextcloud-gpodder/discussions/91> implementation.
Are you interested in joining the discussion about the specification and maybe even implementing the specification into gpodder when the spec itself is mature enough?
We are planning a meeting in early October where we can share and discuss our ideas for the specification and get the opinions, experiences and ideas of other podcast client maintainers on it, and we'd love to invite you to the meeting if you're interested. We plan to send out a (doodle) form where we can schedule a time for the meeting when everyone is free.
Cheers
Jonathan
<OpenPGP_0x8F3038447BC0CF8B.asc>
