Unifying commands for settings

[jugglinmike]

The proposal currently organizes commands for interacting with settings within a notional "extension module." It's presented as a parameterized template that describes any number of distinct modules--one for each AT. This structure involves abstracted command names like <vendor>:settings.getSettings where "<vendor> is a placeholder for an implementation-defined prefix for the extension module."

The proposal would be easier to read (and write) if this was instead specified as a single concrete module for all vendors named settings. It seems to me that the commands in the abstracted module are already so loosely-defined that they don't benefit from being namespaced in vendor-specific extension modules. I also believe that such a module would support future revisions which incrementally standardize the behavior (e.g. by introducing specific settings that all implementations must be able to "set" and "get").

The simpler structure seems sufficient (and therefore preferable) to me, so I assume that there's a reason for the more complex solution which has already been drafted. That said, I can't infer the reason, nor can I find it in meeting minutes. I'm posting this issue to help learn (and document) the rationale and to learn whether a simplification like the one I described is feasible.

[jkva]

@jugglinmike I agree with your observations. So far when I was developing the NVDA automation, I've found the particular NVDA:settings.getSettings not particularly helpful compared to a generic settings.getSettings since the connected session itself already explicitly exists with a NVDA instance, and which settings to get or set would otherwise be implementation-specific.

So yes, I'm all for simplifying this specification in the fashion you've proposed.

[jugglinmike]

Thanks for your input, @jkva! I've submitted a patch which applies this change via gh-65.