Skip to content
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

Add protocol command to disable the listing of playlists in the root folder for the lsinfo command. #2106

Closed
jcorporation opened this issue Aug 30, 2024 · 2 comments

Comments

@jcorporation
Copy link
Member

From #2102:

I can imagine 4 ways dealing with this deprecation:
1. leave it as it is, forever
2. remove it completely
3. make it a per-connection setting
4. make it a global config option

This is 4, but I fear it's the worst way. No user knows about this protocol-level detail and no user should have to know about this. This means no client can ever take advantage of this. 1 is bad because nobody likes to support deprecated legacy stuff, and it may require client-side kludges to suppress it. 2 is bad because some random client may rely on this, and if somebody complains, they're right.

3 seems like the best way to deal with this: every client can decide; newer clients can explicitly opt into new protocol semantics, easily. We just need a protocol command for such an opt-in. I had been thinking about this a few times, but never came up with a design.

We have something similar with tag types: the "old" way to enable/disable tag types is the metadata_to_use setting, but this discards tags while scanning; it's a fragile design that doesn't allow clients to opt-in and opt-out, meaning either they have too much protocol overhead or not enough information. Then I added a tagtypes command which allowed clients to choose exactly which tag types they were interested in. This is fully backwards compatible, but allows modern clients to reduce overhead.

@jcorporation
Copy link
Member Author

jcorporation commented Aug 30, 2024

2 is bad because some random client may rely on this, and if somebody complains, they're right.

You mark this behavior as obsolete since years, but you will never deactivate it? I would prefer to remove it, but it is your decision.

I think we should introduce a general command so that we can make further behavioral changes opt-in. and add also a command to list the deprecated behavioral's or add it as output to the config command.

@jcorporation
Copy link
Member Author

#2123

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant