-
Notifications
You must be signed in to change notification settings - Fork 1
2024 02 27
Georg Krause edited this page Nov 24, 2024
·
1 revision
- Maintaining a WebCal calendar of meetings sounds useful, so that people can see the meetings in their calendars :::info Meet two times per month, to speed it up:
- First week: any day, any time (evening?) (TBC)
- Third week: Tuesdays 12:30 :::
:::info Prior meetings to episodes 2023-05-30 Episode fields: https://pad.funkwhale.audio/oCfs5kJ6QTu02d_oVHW7DA# 2023-07-11 Episode fields: https://pad.funkwhale.audio/FkuIqtPGT-ynYKqBieHffw# 2023-09-05 Identification: https://pad.funkwhale.audio/s/T-yx14DsH# :::
Kasts uses subset of gpodder.net API
Additional data point notices (to the ones defined here)
- playback position (used for multiple purposes)
- episode status (played or not): inferred from playback position (if close to end of episode). workarounds in place if episode is marked as played.
-
new status: would link with 'Inbox' for AntennaPod. Need a clear description of what that status means. AntennaPod: any manual action (play, download, swipe out of Inbox) - Kasts more or less similar. Can base definition on 'manual action by user'. But we should also be careful with being too strict/opiniated, so the definition works also for other projects.
- episode/new status combinable? (mutual exclusive)
- exchange as bunch of booleans (new Y/N; played Y/N; archived Y/N) or as an array, or a string. If mutually exclusive (across all clients/players), it can be an ENUM (set of pre-defined strings).
- Object rather than array. Should cover 'technical' (metadata status), e.g. bookmark is rather about the content, so should not go in, while download status should go in this Object.
-
bookmarks/favourites: can submit, but would have to currently go through each individual episode, so not implemented
- currently implemented as boolean, but feature request for labels. Could be 'tags' for episodes. Something potentially down the road.
- should be not-core? Endpoint is core and call as well, should we define core/optional at field level?
-
download status: also covered in gPodder, but bug in implementation: fails to update metadata (will not check timestamp and ignore if value exists already). If data synced, then download to be executed immediately? Use more as a flag of intent (want/should be downloaded) rather than an actual current status. We expect that clients will have option to turn off. Specify expectation in docs: leave open for clients if they want to download immediately, download later, or never download if not possible/desired to download when this data is received. However: which client then takes precedence? (If not downloaded, sync new status? Requires a download status sync setting at client level.)
- Proposal: make opt-in data, expect client to respect download status if enabled. Delayed download (e.g. wait for WiFi) is permitted.
- episode length/duration: sometimes declared length is different from actual length (diff of couple of seconds is common). Also many feeds don't have length. Needed for the user? Probably not - can be taken from file itself.
- bulk sync of episodes (playback state, bookmark/favourite): will have 'all changes since' so we're good there
-
Core/Optional:
- Currently endpoints and calls can be core. What about field level?
- Can declare action as core, but identify optional-for-client field/data (expect server to have all fields, in order to pass on the data).
- Need a way to identify this at field level in specs. TBC.
- E.g. RSS reader would not be 'OPA-compliant' as it cannot store playback position, but it could still kinda work.
-
Timestamps:
- One timestamp per field unnecessary overhead on the server side?
- Exceptions: dedicated timestamp for last_played. Could introduce timestamps for all other 'sensitive' fields (e.g. favourite). Are there fields that are non-critical? E.g. 'new' status could cause trouble also
- Concurrency in REST APIs:
- before you come online get most recent data, and/or
- only change this if it has not been modified since this date
- then do conflict resolution at client side
- typical situations for nasty things.
- first client, do things un-synced (e.g. offline)
- second client, do things with sync
- go back to first client, go online & pull updated data
- gPodder approach: not sync current state, but sync all changes since then including their timestamp. Having full history is really expensive, and doesn't provide benefit over timestamp per field.
- Agreement: Having timestamp per field helps, but might still cause issues when clients don't store timestamps of local changes (rather than submitting timestamp upon sync). We can include in specs: SHOULD, but responsibility of client, or MUST have one (for OPA-complience).
- if the client says 'fetch me data for this episode changed since x', then the server can just provide that info (no additional data being sent over)
- TODO: criticially examine which of the fields need a timestamp. Think of naming scheme for timestamp fields & JSON structure for endpoints.
- We have an idea/approach, but need to confirm this for Kasts & AntennaPod. We'll try to make a meeting happen with Hans-Peter & Bart
- We can have openAPI pages in starlight
- Ciarán will check for email with Funkwhale SteerCom (regarding CoC)