General Feedback

[KatrinIhler]

I don't have the time to split this up into different threads, but I thought I'd at least post the notes I took while reviewing.

In general I can say that I didn't object as much as I thought I would. :D It's certainly daring and I might disagree or worry about some aspects, but it's a proposal worth entertaining.

General

• Really like keeping most stuff in the db and exporting as needed
• also like one source of truth for everything
• Removing publications would resolve a few problems, but it does worry me
• Too much focus on the APIs in this proposal, not enough focus on internal implications for me
  • Also mild complaint: The search API didn't change "a lot" bc of the move from Solr, imo

APIs

• Don't mind merging /search & /api in general (but will break a loot of integrations :(), but
  • search is read-only & can theoretically run on multiple nodes, the external API currently isn't and can't

Event

• Don't rename to video -> lots of confusion with tracks & video streams already
  • Do keep naming consistent, e.g. not event and episode and recording
  • I do like recording, but what about livestream-only? But then, even that is being recorded in the moment...

ACL

• Imo we could even say that write needs/implies read, as we do in a couple of places already
• Imo roles need to allow the same characters as username unless we do matching of role and user in a different way altogether. Sanitation is the devil.

Metadata

• No more xml, json above all, wheee
• I like the promised properties
• I do like mapping Dublincore on the fly
• iirc OAIPMH mostly links assets rn with a bit of metadata around it
• I do like the extra metadata
• careful: start date is currently the bibliographic start date, not the scheduling start date
  • in general, how do we handle the data the scheduler currently has?
• suggestion: add ingested additionally to created?
  • more (explicitely named) date fields = less confusion & discussion about what they mean?
• duration representing the cut length feels counterintuitive
• I really like the updated timestamp
• What about marking additional metadata as required/read-only? (e.g. series)

Assets

• definitely don't mark each track as live, but event as a whole
• don't know how I feel about enforcing flavors yet - but if we do it, we could enforce some rules for tracks as well (e.g. /source)
• I do like the updated field
• write for internal asset should be enough (though a bit counter-intuitive :/)

Re: Open questions

• I do like the idea of some kind of versioning to undo changes. We just got the snapshots to actually be useful!! (If not quite practical)
• Why are hardlinks evil? Definitely don't do for small files, but might still be useful for big files e.g. videos (event duplication, ...) ? Otherwise storage might explode for some
• Some size limitations for metadata fields sound reasonable, but don't be too restrictive as not to break migration
• Changing metadata is already possible while scheduled, could be possible while workflow is running (workflow just runs on old state)?
  • While we're at it - I assume some form of workspace/WFR/temporary processing data still needs to exist for this model to work?
• PLS let us not change ids!!

My questions

• How much are we willing to change external endpoints?
  • requires updating lots of integrations
  • people might not update
• How much do we want to limit the flexibility the workflow system currently provides?
• Does this data model solve the problems we currently have? -> would like to see those listed somewhere

[KatrinIhler]

@LukasKalbertodt Pling :D

[LukasKalbertodt]

Don't worry, I am notified of anything happening in this repo ^_^

[LukasKalbertodt]

I don't have the time to split this up into different threads, but I thought I'd at least post the notes I took while reviewing.

While I do appreciate the general feedback (also just positive feedback, that would be misplaced in a PR), I do think we should really use GitHub threads for all individual discussion topics. I went ahead and moved all your comments to the relevant PRs. But after having done that: please do it yourself next time 😅 it is confusing for everyone to see my profile picture next to your statement.

I'll reply to some general points here:

Too much focus on the APIs in this proposal, not enough focus on internal implications for me

Well yeah, it is mostly an external view that I'm describing, which I think is useful for the most part. Whenever you worry about some specific internal implications, please mention those.

duration representing the cut length feels counterintuitive

Can you elaborate? Ideally as a comment in the metadata PR on the relevant line.

What about marking additional metadata as required/read-only? (e.g. series)

I also don't quite understand what you mean by that?

How much do we want to limit the flexibility the workflow system currently provides?

This is not really part of this proposal. While the data model changes, the workflow system can pretty much stay the same I think. Of course, some changes need to be made, but it wouldn't change how powerful it is. That said, I wanted to sketch out an alternative in the future...

Does this data model solve the problems we currently have? -> would like to see those listed somewhere

Some? I thought I addressed this sufficiently in the "goals" section in the introduction?