-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Structured way of specifying configs #198
Comments
Thinking about this more we could make users like
So the user just gives us a list of all the names the same user has and as we read users from a system we see use this to determine what user it maps to and also store the name of the user in a given server. We could do similar with libraries etc. Would make the the json a little less complicated.
|
Yeah that structure sounds good. So we would do the user mapping from user1 to "name in plex" and "name in jellyfin" and "etc" and sync all watch progress from user1 to all of those existing names on each server. That makes sense to me. users would be "users": {
"user1": {
"sync": {
"Jelly": [
"Plex2",
"Plex"
]
},
"names": ["user", "etc"]
},
"user2": {}
} user 1 is only synced from Jelly to Plex and Plex2 and it can match on user1, user and etc libraries would then be "libraries": {
"Movies": {},
"Shows": {
"sync": {
"Jelly": [
"Plex2",
"Plex"
]
},
"names": ["Tv Shows", "TV Shows"]
},
"Anime Shows": {}
} Movies and Anime Shows to all servers that have a library with the exact same name |
Here is a fully complete json for documentation purposes {
"sync": {
"plex": [
"emby"
],
"Jelly": [
"Plex2",
"Plex"
]
},
"users": {
"user1": {
"sync": {
"Jelly": [
"Plex2",
"Plex"
]
},
"names": ["user", "etc"]
},
"user2": {}
},
"libraries": {
"Movies": {},
"Shows": {
"sync": {
"Jelly": [
"Plex2",
"Plex"
]
},
"names": ["Tv Shows", "TV Shows"]
},
"Anime Shows": {}
},
"servers": {
"plex1": {
"type": "plex",
"baseurl": "http://localhost:32400",
"token": "SuperSecretToken"
},
"plex2": {
"type": "plex",
"baseurl": "https://nas:32400",
"token": "AnotherSuperSecretToken"
},
"emby1": {
"type": "emby",
"baseurl": "http://localhost:8097",
"token": "SuperSecretToken"
},
"emby2": {
"type": "emby",
"baseurl": "http://another_emby:8097",
"token": "AnotherSuperSecretToken"
},
"jellyfin1": {
"type": "jellyfin",
"baseurl": "http://localhost:8096",
"token": "SuperSecretToken"
},
"jellyfin2": {
"type": "jellyfin",
"baseurl": "http://nas:8096",
"token": "AnotherSuperSecretToken"
}
}
} |
over all I think this looks good. Based on how the code end's up being you might want to tweak it. What I was thinking was as we read users from the system we create a user object store the name from various servers for that user (if that user has different names) Then when we are doing lookup's we do not check if this user name is in the list, instead we just query the above object and say give me this users name in plex etc. Figured that might make the code easier to write. Just a thought :). Similar approach could be done for libraries as well. When I was reading the code I was seeing various checks where we were checking for the user in keys and values which I found hard to follow. Also we can have sync override settings at library level as well? What would be the order of preference? For example lets say global: sync plex -> jelly + emby What would/should we do in this case? when we sync libraray1 from plex to jelly we do it for all users expect for user1? |
I think it would go library > user > global in order of preference so yes what you said was correct. library 1 is synced from plex to jelly for all users except user1. |
One thing this new structure is missing is a blacklist option. Whitelist is handled by including the options you want for users and libraries since without it it will do all objects. |
Another thing to keep in mind is this change will break unraid since theres no real easy way to handle something like this so the old method will have to stick around and have a function that converts it to the new structure like mentioned before. |
Having a more structured way of specifying configs could allow users to specify any number of servers and sync them how they please. For example
If we want to remain backwards compatible that is doable. Something along the lines of:
Some unknowns:
The text was updated successfully, but these errors were encountered: