Specification draft #2
Conversation
Very first draft of a specification
Co-authored-by: ChunkyProgrammer <78101139+ChunkyProgrammer@users.noreply.github.com>
|
@ChunkyProgrammer Thanks ^^ |
README.md
Outdated
| #### > `"thumbnail"` | ||
|
|
||
| The URL to the user/channel's thumbnail. |
There was a problem hiding this comment.
I feel this should be an optional field, since:
- It's not really necessary for importing subscriptions.
- Can change and 404 in the future.
It's also ambiguous whether this should be a direct link to the image or a proxied URL to the media.
There was a problem hiding this comment.
resolved in 5a9c3d9
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. |
|
|
||
| The visibility of the playlist. | ||
|
|
||
| Accepted values: "public", "unlisted", "private" |
There was a problem hiding this comment.
There should also be a value for when the playlist is stored locally rather than on an external server.
There was a problem hiding this comment.
This part of the spec only covers user-created playlists.
I think that saved/subscribed playlists (= not created by the user) should be stored differently.
Signed-off-by: Samantaz Fox <coding@samantaz.fr>
Signed-off-by: Samantaz Fox <coding@samantaz.fr>
|
I've made the changes that were proposed in the various reviews above (may have missed some, sorry):
|
Signed-off-by: Samantaz Fox <coding@samantaz.fr>
| #### `"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!
| 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.
Very first draft of a specification