Discuss: remaining topics #3
Conversation
| At most, it stores a path relative to the configured `storage.dir`, but potentially in an even more implicit way. | ||
|
|
||
|
|
||
| (¹) File system = local file system, or NFS, or S3 storage or potentially others. |
There was a problem hiding this comment.
If we are so bold, maybe make S3 more like the default location 🙈?
Do we still differentiate between asset manager and delivery for locations? If we mix the two, this can be difficult for configuring serving files. If we just put everything in one storage.dir and expose that to the webserver, how to check what files should not be allowed to be served (e.g. source files).?
|
|
||
| :::danger[Open questions] | ||
|
|
||
| - (1?) Java famously has no/bad support for unsigned integers. Decide how to deal with that: do we just give up one bit or do we require proper unsigned usage via `Integer.*Unsigned` methods? Either way: these values must never be negative! |
There was a problem hiding this comment.
Just use validation annotations? So yes give up one bit.
| - Arrays as arrays | ||
| - Tuples as arrays | ||
| - `Map<string, string>` is serialized as object | ||
| - `DateTime`: as ISO 8601-compatible formatted string. The ISO standard actually allows a number of different formats by ommitting parts of the string. Opencast shall format all date times as either `YYYY-MM-DDTHH:mm:ss.sssZ` or `YYYY-MM-DDTHH:mm:ssZ`, i.e. only the sub-second part is optional. The parts on this format string are best described in [the ECMAScript specification](https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date-time-string-format) (which again, is a subset of ISO 8601). Only thing of note: `Z` could either be literal `Z` or a timezone offset like `+02`. |
There was a problem hiding this comment.
Why allow variability? Maybe always require sub-seconds and UTC?
There was a problem hiding this comment.
Mh I guess the subsecond thing is fair, the only reasons for the possible omission I can come up with could also be used to argue for the possible omission of seconds.
The timezone is different tho: yes, when you just want to communicate an instant, always UTC is a good idea. But sometimes you want to communicate the timezone as well, so that the frontend could for example show "this lecture starts at 10am local time (which is 2pm your time)". For that to work, the frontend need to know what the local time is. Of course we can argue whether that is ever important, but to me it feels semantically correct to store stuff like bibliographical date with timezone. Sure, technical timestamps like updated/modified: always UTC, attaching the server timezone makes no sense.
| - `read`: generally, gives read access to an entity | ||
| - `write`: generally, gives write access to an entity (changing or deleting it) |
There was a problem hiding this comment.
@KatrinIhler said:
Imo we could even say that write needs/implies read, as we do in a couple of places already
Adding this right now might be more confusing than helpful. I will add more examples in the future.
We already have more than enough to figure out, lets just not do that.
4 participants
This discussion PR is for everything that is not covered by more specialized PRs.
To add new comments, go into the "files changed" tab and comment on individual lines or sections of lines. Or you can comment on existing discussion threads here. If you feel like you want to start a discussion about a broader topic (than something mainly referencing a few lines), consider open a new discussion here.