search

voc / schedule

http://c3voc.de/wiki/schedule
14 stars 18 forks source link

Draft: add additional flag for do_not_stream / recording optout enum #130

Open saerdnaer opened 10 months ago

saerdnaer commented 10 months ago

relates to #117

schedule.json schedule.xml
missing, or
"do_not_record": false or
"do_not_record": false, "do_not_stream": false, | <recording>…<optout>false</optout></recording>		 We enable the live stream and create a recording, which we publish without any additional approval by speaker
"do_not_record": true, "do_not_stream": true, | <recording>…<optout>true</optout></recording> The speaker does not want a recording of any kind. We will remove all personnel, and maybe even switch off all cameras
"do_not_record": null, "do_not_stream": false, | <recording>…<optout>maybe</optout></recording> NEW: We are allowed to create a recording / enable the live stream; but the speaker can decide afterwards if we can publish it
"do_not_record": null, "do_not_stream": null, | <recording>…<optout>unknown</optout></recording> NEW: We don't know if a recording will exist and recommend all on-premise participants to attend the event in person
saerdnaer commented 10 months ago

@johnjohndoe It's complicated... For a proper solution we should first think about the UI in which the speakers performs this choices... See https://git.cccv.de/hub/hub/-/issues/373#note_18383 for more information.

This PR was thougth as a first step for 37C3 Saal E (SoS Lightning)... but we probably won't find the time to do it properly this round...

saerdnaer commented 10 months ago

I added a table with a first mapping between the JSON and XML variants to the pull request description

johnjohndoe commented 10 months ago

I am still struggling with the negation (do_not_..) and the combination of recording and streaming. I feel this makes it unnecessary complicated for users of this API. Even if other related infrastructure parts handle these entities different I would decouple the API from these aspects (especially UI). Here is a proposal:

schedule.json schedule.xml Meaning
"has_recording": true, "has_live_stream": true <has_recording>true</has_recording>, <has_live_stream>true</has_live_stream> We enable the live stream and create a recording, which we publish without any additional approval by the speaker
"has_recording": false, "has_live_stream": false <has_recording>false</has_recording>, <has_live_stream>false</has_live_stream> The speaker does not want a recording of any kind. We will remove all personnel, and maybe even switch off all cameras
"has_recording": maybe, "has_live_stream": true <has_recording>maybe</has_recording>, <has_live_stream>true</has_live_stream> NEW: We are allowed to create a recording / enable the live stream; but the speaker can decide afterwards if we can publish it
"has_recording": unknown, "has_live_stream": unknown <has_recording>unknown</has_recording>, <has_live_stream>unknown</has_live_stream> NEW: We don't know if a recording will exist and recommend all on-premise participants to attend the event in person

As these fields would be new to the json/xml API clients could migrate at their own pace without being broken.

saerdnaer commented 10 months ago

The problem is that we already have 'do_not_record': Boolean in schedule.json and <recording><optout>true</optout></recording> in schedule.xml – so we have/should somehow to be compatible with these exiting fields.

But yeah, we should stop with this asymmetry between the json and xml variants.

johnjohndoe commented 10 months ago

I imagine that adding semantic versioning to the schema, json, xml would allow to introduce new fields and also to deprecate and remove old fields.