2024-02-27 12:30 === ## Next meetings - 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 ::: ## Episodes :::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](https://pad.funkwhale.audio/FkuIqtPGT-ynYKqBieHffw)) * **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. ### General considerations to data points * 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. ### Episode identification * We have an [idea/approach](https://pad.funkwhale.audio/s/T-yx14DsH#Episodes-endpoint), but need to confirm this for Kasts & AntennaPod. We'll try to make a meeting happen with Hans-Peter & Bart ## Website * We can have openAPI pages in starlight * Ciarán will check for email with Funkwhale SteerCom (regarding CoC) ###### tags: `project-management` `meeting-notes` `OpenPodcastAPI`