robstryker
commented
1 year ago As an afterthought, perhaps 'never' should really be 'never' but a fourth option of rejecting all current recommendations of a given extension, but being open to new recommendations by new requesting extensions in the future, be added? ie, reject the 5 extensions that ask you to install vscode-java now, but, if a new extension you install wants to recommend it, you get that as a new popup.
@fbricon Maybe before you rush off and publish it, I should outline some of my concerns so they're built into the usecases.
I have two extensions, vscode-server-connector and community-server-connector. Both can be installed independently of each other, and one or both may be installed at a time. In the future, both may recommend jdt.ls. It would be strange for 2 popups to show up in this case.
Furthermore, the existing logic in vscode-java allows the caller to pass in the string used. If two very different extensions use different strings to recommend the same extension, it could be confusing.
For example if vscode-server-connector wants to reccommend vscode-java, and so does another 3rd party extension or other redhat extension I don't know about. But if vscode-server-connector has a message like "We highly recommend vscode-java for JEE web-app development" and the other says "Do you want to install the vscode-java extension for better integration with java-based projects"?
There's two concerns here with the above. First is the user experience. A single popup saying 5 extensions recommend you install jdt.ls and maybe listing the messages each individual extension wished to use might be preferred?
Second, the backing store. It seems the choice is saved based on the extension being recommended. But there's a usecase where that may not be appropriate. Imagine, for example, a user installs an extension that lightly benefits from vscode-java, and recommends it, and a user selects 'never'. But then later, a user installs a very different extension that more strongly recommends vscode-java. The backing store is now holding a 'never' for that extension id.
It may be more appropriate to store the responses on a recommender -> recommended pair structure.
In this way, if 5 extensions recommend vscode-java, and we get a single popup listing those 5 recommendations for this single extension, and the user selects "Never", it would store that extension1+vscode-java=never, extension2+vscode-java=never, etc. And then if later, a user installs a sixth that also recommends vscode-java, the backing store is able to recognize that this is a NEW recommendation and should not be covered under the existing rejections.