Specification draft #2
Conversation
Very first draft of a specification
Co-authored-by: ChunkyProgrammer <[email protected]>
|
@ChunkyProgrammer Thanks ^^ |
FireMasterK
left a comment
FireMasterK
left a comment
There was a problem hiding this comment.
I also feel we should have a decoupled playlist and subscription files.
README.md
Outdated
|
|
||
| #### > `"videos"` | ||
|
|
||
| An array of `String`. |
There was a problem hiding this comment.
Should we add thumbnail, duration and published date (utc) optional fields for the video?
There was a problem hiding this comment.
Probably not as these can just be fetched by the app, and just bloats the format for no good reason.
There was a problem hiding this comment.
I think it should be consistent across the document, so either an (optional) thumbnail is allowed in all places, or it is not allowed anywhere
There was a problem hiding this comment.
I've made the thumbnail present everywhere, but I don't think we should save more metadata in here.
I'm afraid that it'd grew out of control.
Or maybe just be able to choose which you want to export within the app. |
Signed-off-by: Samantaz Fox <[email protected]>
Signed-off-by: Samantaz Fox <[email protected]>
|
I've made the changes that were proposed in the various reviews above (may have missed some, sorry):
|
Signed-off-by: Samantaz Fox <[email protected]>
| #### `"watch_history_present"` | ||
|
|
||
| A Boolean. | ||
|
|
||
| Indicates whether the special playlist `watch_history` was included in the export. |
There was a problem hiding this comment.
Should we really be doing this? Watch history can have additional fields such as the watched till duration, and additional metadata. I would suggest an additional format to store this.
There was a problem hiding this comment.
This field is only here to indicate if the watch_history file is part of the export.
The format of the watch history can still evolve regardless!
There was a problem hiding this comment.
@FireMasterK if that confuses you, I can reword that part!
Right now, videos in history and regular playlists are the same objects, but that's definitely going to change ^^
There was a problem hiding this comment.
@FireMasterK if that confuses you, I can reword that part! Right now, videos in history and regular playlists are the same objects, but that's definitely going to change ^^
That makes more sense! I think they can be reworded once we finalize a specification for watch history too.
But, in such a scenario, can't we remove this field altogether?
There was a problem hiding this comment.
I was thinking to make some files optional during the export (like the watch history).
This field's purpose is ti tell the importer whether that file is supposed to be present in the export.
| The description of the playlist. | ||
| Format: plain text (? TBD) | ||
|
|
||
| CAN be nil; In this case, the parser MUST assume an empty `String`. |
There was a problem hiding this comment.
Why is it assuming an empty string if the value is nil?
There was a problem hiding this comment.
Agree, I think it's perfectly reasonable to assume null for a description if none was ever set.
There was a problem hiding this comment.
I probably need to improve the wording... The idea is that nil and empty string have to be considered the same (that is, no description is present).
There was a problem hiding this comment.
Ideally there should only be null if there is no description, and otherwise there is a string.
Very first draft of a specification