2024 11 21

2024-11-21 noon

With keunes, cos, mogway & gcrk

Fundamental approach

cos: Are we doing the right thing? Why take gPodder-approach, with central server.

mogwai: Frequent request also for Kasts. Can have multiple clients talk to the same file, causing conflicts. Also, all clients then need to do the exact same thing. (Would work in a walled garden system, but in our open and varying ecosystem it's opening a can of worms.)

This approach is proven - there are weak points, but that would be a massive undertaking (given that already the approach with a sanitizing server is taking us long).

Could maybe be a follow-up once we've defined the API, to start building a shared data model (similar to calendar events).

Versioning & capabilities

Building on last meeting. Key question: how much complexity vs how much flexibility. Agreed approach to have fewer major versions.

Having the version identifier as part of the version name. Problem: can't tell if version is bumpted or new implementation from the ground up (by someone else who wasn't able to think of a creative name). This is the feature/purpose, though.

{
  "capabilities": {
     "openpodcastapi::betav1",
     "openpodcastapi::core",
     "openpodcastapi::corev2",
     "openpodcastapi::optional": [
        "coversync",
        "queuesync"
     ],
     "openpodcastapi::optional::v2": [
        "coversync",
        "queuesync"
     ],
     "othergroup::socialsharing"
  }
}

We want to keep all possible combinations of different versions.

Scenarios to think about:

• If in core v1 we need queue-sync as optional, and then becomes part of core v2. In v1 optional must be advertised, in v2 it should not be advertised. How to deal with that?
• others? (we should think of some which we then can check)

Having versioning for the optional endpoints adds complexity, but allows to move on with optional endpoints without changing/breaking core.

Optional fields in core endpoints

Server expected to handle these? Optionality applies to sender;

• Server needs to implement optional fields, and have full support for it.
• Optionality, a discussion ongoing about two different contexts:
  • clients' support (e.g. episode is_favorited)
  • makes sense to send or not (e.g. next page)
• We need to differentiate between these two. Maybe we should rename 'optional' endpoints to 'extension' endpoints.
  • Can we not specify for each field if it's optional in the sense of next page? No, we should specify this: to ensure that devs just won't send guids because they prefer not to. Also, many if statements needed on client side, to cover for optional fields.
  • gcrk will create a PR to change 'optional' to 'extension'. Then once concluded, also to be changedin in the episodes endpoint PR.

tags: project-management meeting-notes OpenPodcastAPI